[Modules] Module variables

Mark van Gulik ghoul6 at home.com
Thu Aug 30 03:04:17 UTC 2001


On Wednesday, August 29, 2001, at 04:59 pm, Lawson English wrote:
[...]
What I am suggesting is that two new types of access be defined for
> Smalltalk:
>
> Module instance variables -accessible only by objects of a class or
> sub-class defined within the module -roughly equivalent to package 
> access in
> Java
>
> Module global variables -accessible via the pool dictionary strategy 
> ONLY to
> classes defined within a module (and to any subclass?) -roughly 
> equivalent
> to package access for pool variables.

Interesting.  Avail has local variables, arguments, instance variables, 
and module global variables.  Instance variables are only accessible if 
you've exported their names from the module, so that makes them Module 
instance variables by your definition.

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.

The module global variables aren't quite what they seem in Avail - far 
from being mere syntactic salt like C++'s and VW's namespaces, modules 
in Avail have identity -- a module is roughly an occurrence of a 
compilation and initialization of a module file.  Thus, you can have two 
versions of a module in your image without there being any problems.  
You'd probably want to have two module files with distinct names, but 
even that isn't strictly necessary (compile&load, edit, save, 
compile&load).

This was by design, specifically to address the safe, 
programmer-assisted migration of objects between versions of types.  
Most of that isn't coded yet, but the design artifacts are in place.

-Mark




More information about the Squeak-dev mailing list