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

Andreas Raab Andreas.Raab at gmx.de
Thu Aug 16 19:34:31 UTC 2001


Stephen,

> > But where is your proposal different? As far as I can see you
> > do resolve the symbol #add: into different objects, namely
> > #42add: (or #56add: for that matter).
>
> The difference is that "'add:' asSymbol" would always yield the same
> object no matter which module you are in.

This could be done in either approach. Since you do have to modify the
compiler to generate the prefix bytes you could equally well define that
only a compiler lookup will go through the local selector name space.

> > And wouldn't it be
> > simpler to do something like implement #42add: as
> >
> > Object>>42add: anObject
> > 	^self 56add: anObject.
> > Object>>56add: anObject
> > 	^self add: anObject.
>
> Actually, I don't think that is simple at all...a package that is made
> dependent on yours, that uses the #add: method, would have to
> modify all of its uses of #add: to #42add:

Not true at all. If your module '76' imports module '52' then the only thing
it needs to implement is Object>>76add: as 'self 52add:' (and any other
messages that should go through '52'). Mind you, the above is equivalent to
what you are proposing; only that where you're using an extra "package
import array" and a modified VM I'm just proposing to dump all the
interesting method relations up in Objects method dictionary.

> ...name clashes would be easy...all of these weirdly named
> selectors would look bizarre, and the meaning behind
> them would be difficult to discern by a new user...it is a
> heavy burden for the developer (particularly a new user)...
> it is more difficult for the system to determine dependencies
> (it would have to search for packages that implement #42add:
> as opposed to knowing this directly).

I hear ya. But please keep in mind that I was never ever arguing for
actually doing anything like the above. All I was saying is that *if* one
wants to do some experimentation it might be simpler *not* to modify the VM
to begin with. I'm certain you realize that my approach is 100% equivalent
to what you are proposing and so the only difference is that you would need
a modified VM to begin with and I wouldn't ;-)

> I'm not convinced by your position that it would be 1) too
> difficult or impossible to implement,

I don't think I ever said that.

> or 2) that it would make the system more difficult to use
> (in fact, I think it would make the system considerably easier
> to work with).

That remains to be seen (but I think it's somewhat pointless to construct
theoretical cases here ;-)

Cheers,
  - Andreas





More information about the Squeak-dev mailing list