[prev in list] [next in list] [prev in thread] [next in thread] 

List:       e-lang
Subject:    Re: [e-lang] Bug: seedVat/2 and similar are confusing
From:       "Mark S. Miller" <markm () cs ! jhu ! edu>
Date:       2007-01-18 4:30:34
Message-ID: 45AEF7EA.1060500 () cs ! jhu ! edu
[Download RAW message or body]

Kevin Reid wrote:
> On Jan 14, 2007, at 15:13, Mark S. Miller wrote:
> 
>> Should we fix this by deprecating those elements of the current API  
>> that lead one into this confusion, i.e., all seedVat-like functions  
>> in which an existing vat is passed back in as an argument?
> ...
> Now that I understand the problem, my first inclination was to  
> declare this Not A Bug and add warnings to the documentation for  
> seedVat/2.
> 
> However, making multiple identities in a single vat is not something  
> that should need to be done often, though it should be possible.
> 
> Proposal: keep seedVat/2, so that someone trying to do this  
> deliberately doesn't need to duplicate the code in seedVatAuthor, but  
> rename it to something that makes it clear that it's an unusual  
> operation. What comes to mind is "reseedVat", but I'd like to hear  
> other suggestions.


I now plan to do something like this as a staged renaming.

By "staged renaming", I mean,
* Introduce a new method with the existing functionality.
* Deprecate the old method, but leave it in for now as a synonym for the new 
method.
* Retire the old deprecated method in a later release.

All the existing seetVat-like functions do the reseeding as arity-overloads of 
their "run" methods. For uniformity, I'll use the same method name for the new 
method to replace these, perhaps "reseed".


> As a separate item: the "virtualize" naming bothers me. It seems to  
> me that the 'virtual' version is nearly always what the programmer  
> wants, rather than using the peculiar boot-comm system, and that it's  
> not particularly intuitive what 'virtualize' means in this context.

I agree. I'll do something like a staged renaming here as well. It might be 
more of a refactoring, in order to make the typical case easier, but I'll 
still preserve upwards compatibility during the first step of the transition.

-- 
Text by me above is hereby placed in the public domain

     Cheers,
     --MarkM
_______________________________________________
e-lang mailing list
e-lang@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/e-lang
[prev in list] [next in list] [prev in thread] [next in thread]