Adding Modules to Squeak; a proposal

Jesse Welton jwelton at pacific.mps.ohio-state.edu
Fri Mar 16 22:54:12 UTC 2001


Joerg, it sounds to me like you have a rather nice design going here.
There's just one area where I would like to comment.

Joerg Beekmann wrote:
> 
> > III) Module specific class extensions
> > =====================================
> > ** Classes may be extended with methods by modules in which 
> > they are not
> > defined. This provides a home for methods such as isMorph.
> > 
> > Like ENVY.
> > 
> > ** The methods a class understands consists of the methods 
> > defined in it
> > and its super classes as well as the extensions defined in the module
> > corresponding to the sender (that is the senders view of the object).
> > 
> > Interesting. Unlike ENVY -- since it does not take in account the
> > sender. I think this might be a lot of overhead. Is this 
> > really needed?
> > Conceptually, it looks nice, can we think of examples where it is
> > essential?
> 
> I think this is essential as it prevents collisions between extension
> methods defined in unrelated modules. I don't think it will be that much
> overhead generally since the there is a hit in the method cache about 95% of
> the time. doesNotUnderstand will become slower by some substantial factor.

> > ** Look for extension methods after failing (does not 
> > understand). i.e.
> > extensions are in addition to existing protocol.
> > 
> > HMM. Possibly. Or woudl extensions be in the regular method 
> > dictionary?
> 
> No this would defeat the purpose. Note that placing module lookup BEFORE the
> regular lookup creates the object Views that another poster wanted.

It seems to me that this (essentially, module-specific *overrides* of
particular methods) would be considerably more useful for
modularization than merely allowing module-specific additions.  For
example, Morph>>invalidRect:from:, a core Morphic method, currently
has calls to #wonderlandTexture and #isValidWonderlandTexture:, which
makes it difficult to completely unload Wonderland functionality.
Core Morphic should not have to import Wonderland, but Wonderland may
need to clear the texture field whenever a Morph is invalidated.  (In
this particualr case, I don't know if it's true.  Consider it a matter
of principle.)

Also, only checking for additions after the regular search means that
additions are susceptible to being shadowed by later additions to the
base module, which are less likely to be sensitive (if they're even
able to be sensitive) to the needs of the specialized module.  In
short, it's the specialized module which should get to override the
generic version of a method, rather than the reverse.  The only
question in my mind about it is, can it be done without killing
performance?

-Jesse





More information about the Squeak-dev mailing list