[Modules] Name space semantics was: Re: Some of my thoughts

Stephen Pair spair at advantive.com
Fri Aug 17 03:21:06 UTC 2001


> Whilst thinking about the implementation details, don't get 
> stuck on mangling symbols. There is no real need to insist on 
> message selectors being Symbols; the VM either can or could 
> work with any objects that are suitably unique (though even 
> that could probably be waived if we want) including objects 
> that encapsulate the name of the message that we are used to 
> and package/environment/whatever information.

Yes...this may be a much better way to go.  I was thinking that this
would cause too much strain in terms of making the tools cope...but, it
may actually be a lot easier if you make the new class suitably protocol
compatible with symbols.  Also, that way, the only thing the VM really
needs to know is where to look in the module for imported modules.
 
> The bit I see as tricky is the mirrored pair of requirements 
> to do with deciding which Message is meant and when to change 
> (package boundary
> etc) and the tool stuff to make it so easy to use that no-one 
> objects. 

I see it this way...the compiler is package aware...it will generate
selectors in compiled methods using the current module...it will enter
new methods into method dictionaries using a package specific module.
I'm sure there's something I'm missing...

The main drawback would be the additional storage overhead...a simple
mechanism to flatten everything forget about modules would be nice (of
course, then everything would break!).

> Envy is _not_ the answer here... 

Why not?!  Let's just have one big envy server running on an IBM MVS
mainframe that we can all share!  (ok, I'm being silly now)

> Surely we don't want some convoluted system that provides for 
> intricate exceptions (hey, I know a package I rely on has its 
> own form of #fobler: but I want the #foobler: that I know 
> {read, think} the base system uses, so I'm going to do 
> 	myThing {foobler:.Packages.Base}
> and so on) and then a subpackage that does the inverse .... 
> I'm sure you can work it out. If you rely on a package, _rely_ on it. 

This sounds like overriding a method to re-implement the behavior that
your superclass overrides.

> 
> tim

- Stephen





More information about the Squeak-dev mailing list