A refactoring of SM?

danielv at netvision.net.il danielv at netvision.net.il
Fri Oct 25 16:48:37 UTC 2002


It's not quite clear what you mean. 

If you mean being able to load code in a passive manner, so it can be
examined without being active, that's what I'm proposing, and should be
a simple matter of integrating the FCB.

If you're proposing (as I suspect) to make it possible to have
simultanous versions of the same code coexist actively in the image,
that is not what I'm proposing, I don't know how to implement this, and
honestly am not convinced it's worth the mental overhead from working in
such an environment.

Daniel Vainsencher

Les Tyrrell <tyrrell at canis.uiuc.edu> wrote:
> 
> ----- Original Message -----
> From: <danielv at netvision.net.il>
> To: <goran.hultgren at bluefish.se>
> Cc: <squeak-dev at lists.squeakfoundation.org>
> Sent: Friday, October 25, 2002 9:43 AM
> Subject: A refactoring of SM?
> 
> 
> > I've been thinking about your suggestion to add another option for
> > downloading packages and opening the FileContentsBrowser on them.
> >
> > This sounds like a great idea, since this will allow people to decide if
> > they want the changes applied. Especially useful for someone that wants
> > to decide whether to upgrade an image that's grown dear to him...
> 
> That is *exactly* the direction I took with Oasis- Bully!  The next steps
> beyond that are to make it possible to load semantically complete class
> libraries into separate regions, thus allowing the simultaneous use of
> differing versions/implementations at once.  As in:
> 
> http://griffin.canis.uiuc.edu:8080/Oasis/Cross-Dialect+Loading
> 
> There is no need to have to choose one thing over another- have as many as
> you want.  There is no reason this cannot be done.  There is no reason to be
> constrained to the tyranny of the monolithic image.  There is no reason to
> require a central, arbitrating authority deciding what goes in, and what
> stays out... this is YOUR choice, and that of those offering workable
> components.
> 
> - les



More information about the Squeak-dev mailing list