Squid modules

Anthony Hannan ajh18 at cornell.edu
Sat May 10 22:04:24 UTC 2003


All right, I have changed my mind again.  Although my previous
scheme was flexible it was less readable.  The independent selector
methods did not indicate what type of objects the receiver can be,
making it less readable.  So I'm going back to multiple-inheritance of
classes, where all methods are associated with some class.  This is a
little less flexible since class extensions are bound to a particular class
instead of being independent, but it is more understandable/readable. 
To allow full override capability and avoid problems with inheriting
state, instance variables will be implemented as overridable primitive
(accessor) methods.  Also, selectors are bound (has implicit prefix) to
the class that introduced it, avoiding selector conflicts.

So a module contains a set of classes and methods on those classes or
imported classes (class extensions).  A module imports other modules
whose public classes and methods are accessible.  Message lookup
searches the receiver's class hierarchy in both the class's module and
the sender's module and its imports.  Neither module has precedence so
an error is raised if found in both.  Likewise, multiple superclass
branches have equal priority so an error is raised if found on more
than one.

Both modules need to be searched so subclasses not known to the sender
can intercept messages and so class extensions that are known to the
sender can intercept messages.

Cheers,
Anthony



More information about the Squeak-dev mailing list