[Modules] Name space semantics was: Re: Some of my thoughts
jbeekmann at attglobal.net
Thu Aug 16 13:53:46 UTC 2001
As I see it there are 3 ways to deal with package based extensions (methods considered to be part of a package and only
1. Manage the source only. This is how extensions are handled in Envy. Basically when a package is loaded extensions to
existing classes are added. The advantage is simplicity. The disadvantage is the potential for conflict. But this may
not be so large?
2. Associate a collection of compiled methods extending classes with package objects. Upon doesNotUnderstand look
through the packages associated with the context of the running method for an extenstion. This is still reasonably
simple but invocations of extensions will be MUCH slower than standard method invocations.
3. Create multiple caches at the VM level. This is the most complex option and will have a significant space impact.
I waver between 1 and 2. One reason 2 (or 3) are nice, other than the obvious, is this feature will allow us to create a
package mechanism that supports loading multiple versions of the same package without conflict.
From: squeak-dev-admin at lists.squeakfoundation.org
[mailto:squeak-dev-admin at lists.squeakfoundation.org]On Behalf Of Andreas
Sent: August 16, 2001 12:22 AM
To: squeak-dev at lists.squeakfoundation.org
Subject: RE: [Modules] Name space semantics was: Re: Some of my thoughts
> Simple example:
> - "Package A" overwrites the method #add: on OrderedCollection.
> - The method doesn't work properly and brings the system to its
> knees (try it!)
> What I have in mind solves this problem (providing that you are
> developing within a package). (note: people have previously suggested
> that each package resolve the same symbol to a different object, but I
> don't think this is the best way to go)
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). And wouldn't it be simpler to do something like implement #42add:
^self 56add: anObject.
^self add: anObject.
At least there's no need to modify the VM lookup machinery *and* you may
have a chance to actually find out what's happening if you send (what you
think is) #add: to some object.
More information about the Squeak-dev