Henrik,

Just one small comment: It's simple. I like it ;-)

Cheers,
  - Andreas

> -----Original Message-----
> From: squeak-dev-admin at lists.squeakfoundation.org
> [mailto:squeak-dev-admin at lists.squeakfoundation.org]On Behalf 
> Of Henrik
> Gedenryd
> Sent: Saturday, August 25, 2001 11:00 AM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: Re: [Modules] From here to there
> 
> 
> > it would be very helpful if you were cut a bit of slack in 
> the early stages.
> > A lot of slack would be better.  In particular, I've been 
> thinking that it
> > might be useful if you were to go ahead and introduce 
> modules now, but in a
> > fashion where they are more or less just decorations.
> 
> Les,
> 
> this is an excellent point! The 'modularity of modules' 
> faction awards you
> an instant honorary doctorate. (It's probably one of those 
> dubious degrees
> that spam emails want to sell you, but hey, it's the thought 
> that counts.)
> 
> In bringing this idea forward, I think the crucial point is 
> to decide just
> how much 'real meaning' (vs. just decorations) these 
> lightweight modules
> should have. There is a trade-off here: functionality that we 
> leave out will
> not be debugged and improved to working quality. So a 
> Goldilocks balance
> would be desirable.
> 
> So what we need next is to figure out just what would go into such a
> solution. If you recall my posting "[Modules] Let's get things rolling
> soon", much of it applies to this question. The idea was to put out
> something soon that contains just precisely what has to be 
> there at first,
> and then collectively build from there.
> 
> I have been hacking up a Modules prototype derived from Dan's 
> Environments,
> and after thinking just a little about just what would go into your
> lightweight scheme, and with the KISS approach I took, I 
> don't think they
> are very far apart.
> 
> I'd like to see others' thoughts as well about what should go 
> into this
> lightweight scheme. But I think as much of the modularity 
> functionality as
> possible should be placed there, but be designed with a 
> consistent 'opt-in',
> non-forcive policy.
> 
> And we could use some code analysis tools rather early on, 
> too. (There are
> some seeds already.)
> 
> Ok, I have more comments but I'll post the code now for your 
> weekend hacking
> pleasure, and return with more comments later. This is 
> Squeak3.1a-4261 code,
> it should work with 4282 but I just haven't tried it.
> 
> A couple of notes:
> 
> 1. This is a prototype/hack-up, don't take it too seriously. 
> It is highly
> incomplete, buggy, unfinished, etc etc. Beware of the two-headed calf!
> 
> 2. Compare it with my writeup of a modularity proposal. This 
> follows to the
> proposal but does not cover it all yet though. There are some 
> hints for an
> all-encompassing name space, such as Andrew Black suggested. 
> These are just
> hints so far.
> 
> 3. Instructions in the first preamble.
> 
> 4. Note Dan's rudimentary code analysis tools, and his 
> beautiful solution
> that hunts down and rewrites global references in the source code.
> 
> 5. The core is in the category System-Modules, it is rather 
> small. The rest
> is a bunch of patches to make the rest of the system follow 
> this regime (but
> just barely so far).
> 
> Henrik
> 
> 
> 
>