As additional support for idea, Envy provides Class Extensions which do the
same thing.  I have used this concept often in both Visual Smalltalk with
Team/V and IBM Smalltalk with Envy.

The ability to extend the class in this way always seemed like "a source
code management solution" to adding behavior in the system, rather than
subclassing or factoring into collaborating classes.  However, it is so
useful that it is a (sometimes guilty) solution.

Jeff Odell

-----Original Message-----
From: Norton, Chris [mailto:chrisn at Kronos.com]
Sent: Thursday, July 15, 1999 5:14 PM
To: 'squeak at cs.uiuc.edu'
Subject: RE: Radical suggestions


Hi Folks.

~~~~~~~~~
rob van den berg [SMTP:rvdberg at best.ms.philips.com] wrote:

[snip]...However, I don't think that it is such a good idea to be able to
give methods a 'package scope": a class/object should be an atomic entity;
everything belonging to a class/object should be defined in the same place.
You cannot just rip out parts of an object! Apart from the philosophical
implications, it would not like to do maintain software written in that way!
~~~~~~~~~

Rob, I've been using VisualSmalltalk Enterprise for a number of years.  They
have a source code repository mechanism called Team Tools that implements a
PVCS source code repository in a way that is virtually seamless to your
typical developer (in fact, I rarely remember it's there; it's that quiet).

VSE has two source code grouping mechanisms:  the package and the container.
Packages hold code and containers can hold packages and other containers.
It is really quite nice; the tools represent the container/package metaphor
with tree view widgets, much like Bob Arning's Hierarchical morph.

Anyway, one of the best parts of VSE's source code repository mechanism is
its ability to save loose methods in packages that do not contain the
method's class.  This "pluggable behavior" is great!  It allows me to write
all kinds of dirty little test tools to interrogate my objects, without
cluttering my image.  When I'm done testing, I simply unload the package
that contains the test methods.

Another great reason to love loose methods is their implied ability to load
and unload whole applications into and out of your image.  Say for example,
I have loaded Bob Arning's BobsBrowser.  It is almost certain that this
application requires new methods for some base classes (like Browser).  If
Squeak had a team tools mechanism, then I could load in one or more packages
(or a cluster or packages), that contain ALL of the classes and methods that
Bob has added for his feature.  These new methods for Object, Browser, etc.,
would live in Bob's application package and could be seamlessly removed from
the image when the package is discarded.  [Note: these loose methods are
real Smalltalk code; you can modify them, move them to other packages, etc.
Instances of the class with loose methods can execute them if they are
loaded in the image, regardless of where they life in the package/cluster
hierarchy]

Loose methods living in packages that do not contain their class definitions
is not a radical new idea.  It is a tried and true idea that
Digitalk/Parkplace perfected several years ago.  I would love to see this
kind of power added to Squeak.

Best regards...

---==> Chris