On Saturday, August 25, 2001, at 02:00 PM, Henrik Gedenryd wrote:
> ...
> 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 was just curious about how you were handling the default single-path 
inheritance aspect of namespaces in Environments.  I agree that it 
should be possible to delegate name lookup to multiple imported modules, 
as you mention in your proposal.  (ModSqueak and other module proposals 
seem to assume this as well.)  Would this require abandoning the 
Environment-style "MyModule MyClass" message-send name lookup (as 
opposed to VisualWorks-style "MyModule.MyClass" syntax)?

(Apologies if this has already been worked out in an obvious manner.  I 
confess to not being an expert on Environments...)

> 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.

Also, I'm not sure if there's any consensus yet on whether supporting 
"loose methods" (a.k.a. class extensions) should be part of an initial 
lightweight scheme... they're not specifically mentioned in your 
proposal.  I notice that Dan's #reportClassAndMethodRemovalsFor: utility 
does identify loose methods, for example.  (ModSqueak and most other 
non-lightweight proposals support them.)  Whether or not they're 
supported would certainly have an effect on how the initial breaking up 
of the image would be handled.  (e.g. solving the ol' String>>asHtml 
problem by storing that method in its appropriate html-related module)  
I guess I would personally like to see loose methods supported, unless 
it turns your lightweight proposal into a heavyweight one. :-)

Good work on the stuff you've done so far,

- Doug Way
   dway at riskmetrics.com