[Modules] From here to there
Andreas Raab
Andreas.Raab at gmx.de
Sat Aug 25 20:58:08 UTC 2001
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
>
>
>
>
More information about the Squeak-dev
mailing list
|