Name spaces in Spoon

Ralph Johnson johnson at cs.uiuc.edu
Sat May 27 10:36:29 UTC 2006


On 5/26/06, Michael Latta <lattam at mac.com> wrote:
>
> #MAL I think one of the ideas is that you should be able to load a
> #MAL module without modification.  In particular if the idea is to host
> #MAL multiple applications in one image, no modification should be required.

One solution I've seen (I think that Envy did this, but it has been a
few years, so perhaps I am not remembering correctly) is for your
module system to complain if you try to load two modules that want to
change the same method, and the modules are independent of each other.
 If one module is a prerequisite of the other then the latter module
is assumed to know what it is doing when it changes the first.  But if
the modules are independent and they try to change the same method
then they will not load until you tell the system what to do about the
conflict. It is sort of like a merge conflict in a configuration
management system.

> Another potential type of method collision is where a module needs
> some default behavior in all classes and so adds a method to base
> classes like Object.  These methods really have little to do with
> Object and are only going to be sent by the module,.  Often their name
> is based on the module, and so the chance of collision is vrery small.
>  I don't think I've ever seen this kind of collision, though I often
> make this kind of extension of existing classes.
>
> #MAL While having the module name in the selector reduces collisions
> #MAL it also means that the selector does not read as well as regular
> #MAL selectors.

In practice, ths is not a problem, because people don't generate
selector names randomly.  For example, Morphic adds  #isMorph and
#costumes to Object.  It is possible that someone else might add
#costumes to Object, but nobody would try to define #isMorph unless
they were trying to cause trouble.

>
> The third type of method collision is where a module changes an
> existing framework by overriding some of its methods.  This is the
> most common kind of method collision, but private selctors wouldn't
> help, because the whole point is to use the same selectors that the
> framework is already using.
>
> #MAL If you mean replacing a method in one module by a modified method
> #MAL in another module that has a very different semantic.  That is more
> #MAL a matter of having the loader be able to do that.  The methods do not
> #MAL co-exist.  If you mean to
> #MAL implement a selector defined in another module, that will surely be
> #MAL required in any solution.  Not all methods can be private, just as a
> #MAL class in a module would need to be able to override a method in the
> #MAL base class of any classes it defines.

I am not sure what you are saying.  If you are saying "a private
selector system will not solve this problem" then that is the point I
was trying to make.

In my opinion, the first two kinds of problems are easy to fix without
private selectors, and the third problem will not be helped by private
selectors, so I fail to see why private selectors are useful.  I think
this is another case of people getting excited about solving a hard
problem, but it is better to just ignore the problem because it is not
important.

-Ralph Johnson



More information about the Squeak-dev mailing list