on 8/29/01 8:04 PM, Mark van Gulik at ghoul6 at home.com wrote:

> Hm.  The concept you (or someone else) seem to be proposing regarding
> module instance variables is that of a state extension to a class.  This
> would be entirely superfluous in Avail because of my concept of Power
> Set Inheritance, but I can see how it would be useful in Squeak.

Perhaps. I merely wanted to create an extension to Squeak's variable
handling that was based on the existing one. Note that the default is what
you already get from Smalltalk: Module pool = Smalltalk pool &
moduleInstanceVariableNames = instanceVariableNames if the module concept
hasn't been implemented at the lowest level or if there is only one module
used in a project.

It also sidesteps questions concerning namespaces. If there WAS a naming
conflict between a subclass's module pool and the superclass's pool, you
could resolve it by prepending "supermodule::" to the global variable name
(or some other equivalent syntax more in keeping with Smalltalk) without
having to have resolved the general namespace issue.

["supermodule::variable_name" would allow the sub-class to access the global
module pool of the superclass rather than the global module pool of the
sub-class, just to make things clear]



-- 
The real romance is out ahead and yet to
come. The computer revolution hasn't started yet. Don't be misled by
the enormous flow of money into bad defacto standards for
unsophisticated buyers using poor adaptations of incomplete ideas. -Alan Kay
--