Classes as Packages (was: Harvesting infrastructure)

Anthony Hannan ajh18 at cornell.edu
Mon Nov 18 04:30:12 UTC 2002


Hi Colin, thanks for your input.

Colin Putney <cputney at whistler.com> wrote:
> Andreas responded to Anthony much as I would have, thus saving me the 
> trouble. I won't repeat what he said, but I did want to draw attention 
> to the closing remark of his post:
>
> > Besides, I think that even if that scheme could be implemented (which 
> > I have strong doubts about) I don't think very many people could grok it. 
> > Might be worthwhile to consider.
>
> This is exactly what caused 3.3 to fail. It's really important that we 
> keep things simple with 3.4.

What I'm proposing is meant for 4.0, not 3.4.  These changes require
image format changes.  I will create of new version of VI4 called VI5 so
we can start experimenting with these changes.  I am presenting this design
now in case we want to adapt our current approach to packaging in light
of possible future adoption of this design, or something similar.

I think 3.3 failed because the design was poor, the implementation was
incomplete, and the author quit supporting it.  The design lacked
selector namespaces, conflict resolution, multiple versions, first-class
extensions (more on this later), and automatic detection of
prerequisites (particularly through message sends).

I know what I'm proposing includes some radical changes, but I think
these changes are beneficial on their own, plus they make packaging
easier, so I hope people could grok it.

Here is a synopsis of what I'm proposing:

- Multiple inheritance of behavior only (same as I described before in
"Class Dependencies").
- Every selector bound to the abstract behavior which introduced it.  A
behavior can only implement methods for selectors bound to it or its
super behaviors (same as described before).
- Environments representing versions/projects of Squeak containing new
classes/versions and inheriting classes from zero or more other
environments (same as described before).  But now an environment is also
a namespace.  All local and inherited classes/vars of an environment, as
well as their selectors, are visible to methods of classes in that
environment.

Environments form layers of Squeak.  Processes can run with respect to
different environments on the same image.  Classes of an environment can
be downloaded together or individually.  Class prerequisites can be
downloaded with the class automatically, or on demand during runtime.

The key to this design, and any package design, I think, is that class
extensions are first class objects (I make them new super behaviors). 
When they are not first class objects they act like changes to a class. 
Changes is a lot harder to manage and mix than separate objects, so you
want to keep them to a minimum.  In this design, only true behavior
changes need to be managed as changes.  They are managed as versions in
environments that override versions in inherited environments.

Cheers,
Anthony



More information about the Squeak-dev mailing list