----- Original Message -----
From: Paul McDonough <wnchips at yahoo.com>
Date: Tuesday, September 4, 2001 10:38 pm
Subject: Re: [Modules] a summary of joseph's work

> --- danielv at netvision.net.il wrote:
> > As another Squeaker that was there -
> -- As one who wasn't, but is well familiar with the
> ModSqueak code base ... and hasn't weighed into this
> fine discussion for quite a while ...
Hmmm, I guess I was there too, but I don't really have that much to 
add...

> 
> > You want to load two versions of a method at once
> > and manage their
> > co-existance? ModSqueak won't do it, but it'll raise
> > an exception when
> > the conflict occurs on loading, and you can catch it
> > and play around.
> -- there's also the possibility to "load" both
> methods, which must be in separate modules, leaving
> one module "loaded" but not "installed" whilst
> installing the other.  That means both modules are
> under ModSqueak's management and can be edited,
> versioned, sent to other images, etc.; but one of them
> has not been compiled into the current image, and is
> thus inactive, and not available to the other Squeak
> tools and browsers.  NB:  this feature has not yet
> been surfaced into the toolset, and only the rather
> determined developer will want to attempt it (yet).
What I said (and what Daniel meant) was, that if YOU had a way to make 
multiple class/method editions live simultaneously in the image, you 
could hook the ModSqueak installer exceptions and handle them to 
install things the way you wanted them installed. I just give you the 
hammer and chisel, you can be Michaelangelo.

re: toolset - the browsers work on *any* modules you have. If you use 
your own ModuleBuilder subclass to create another orginizational scheme 
and ModuleOrganizer, you can open your browsers just as easily on that.

> 
> [...]
> > Anyway, I think the real issue we should be thinking
> > about is "Given a
> > good load mechanism, a clean (empty?) base SWT
> > image, how does this
> > affect the way we work?"
> > 
> > * Are you going to start working daily in the SWT
> > image? 
> > * and not use all the tools you're used to (Celeste,
> > in my case) but
> > aren't part of SWT?
As Paul said, you can use ModSqueak on a normal Squeak image. Anyway, 
an image is just a throw-away artifact. Back when I worked with Team/V, 
I didn't even bother saving the image. The modular structure guaranteed 
that I could reproducibly rebuild my image from scratch any time I 
wanted- and I did that (at least) every morning
.
> -- ModSqueak is intended to be applicable to stock
> Squeak images as well as SWT.  The work to segment out
> a different code base into modules would still (I
> presume) need to be done.  But it's nothing the
> "Ginsu" wouldn't be able to handle (hrm, actually,
> isn't Ginsu a registered trademark? well, if they sue
> they can only sue for code, right? ;-).
> 
> > 	We might need to start separating those out into
> > modules we can
> > maintain independent of the SqC image.
> -- precisely.
> 
> > * and not see all the new cool eToy stuff SqC is
> > working on?
> > * and anyway, if Lex and Daniel do start maintaining
> > Celeste in a module
> > outside the SqC image, how does this mix in with the
> > updates review
> > team? 
> > * how will I get the bug fixes and tweaks for
> > Celeste, if that's not in
> > the update stream?
> -- I think the end goal (one of them) should be for
> ModSqueak to provide its facilities in a robust
> enough, and distributed enough, fashion for both SqC
> and the rest of us to work in modules.  As long as at
> some point along the chain the source code can be
> converted to a standard such as SIF, or (later?)
> another accepted standard, ModSqueak shouldn't really
> care where it came from.  Changesets can easily be
> translated into Packages, for example, so it's not
> hard to imagine enabling a ModSqueak "server" to talk
> to client images in changeset format.  Having that
> work robustly ... is a tad more difficult to image.

Paul has all the stuff needed to transfer between ChangeSets and 
Packages. Having used both, I must say that the Package format is 
easier and cleaner to use - no unwanted surprises.

-- joseph