Hi--
Yes, Spoon[1] supports multiple active versions of the same class.
Background:
Spoon has no system dictionary, nor does it use "chunk-format"
files such as sources or changes files, or "fileouts". It doesn't use
files at all, apart from object memory snapshots and virtual machine
executables, which are embedded into the Spoon "app" as far as the host
platform is concerned.
Instead of using source code in files, Spoon uses a distributed
live-objects history system called Naiad (short for "Name And Identity
Are Distinct"). Each normal object memory is paired with a special
separate memory, connected by remote messaging, for recording history
information. This special memory is called a "history memory", and the
memory it describes is called a "subject memory". The history memory
stores "edition" objects which describe various development events,
including class and method installation. These editions are managed by
an "edit history" object, which is exposed to its subject memory as a
seamless proxy.
Class installation happens whenever you define a new class, or
change the definition of a class. The edition that describes a class
installation includes all the information needed to replay that event,
to undo it, and to provide context for people studying it later (for
example, the author and the time of installation). Among that
information is the name given to the class at the time. Each edition has
a reference to the previous and next editions. The edit history stores
the most recent edition for the class in a dictionary; the key is a UUID[2].
That UUID is also stored in a slot of the active class object being
described, in the subject memory. When the compiler needs to find the
class object for a name mentioned in source code, it asks the edit
history for the IDs of all the active classes with that name, and finds
all the active classes for those IDs, by traversing the class hierarchy.
If there is more than one class for the same name, the user interface
can help the developer make a choice, by showing some of the additional
contextual information from the edit history.
(The history memory is effectively an application-specific
distributed object database. Multiple subject memories can use the same
history memory, and history memories can federate. From each subject
memory object's point of view, the edit history is just a normal local
object.)
With this organization, the name of each class can be anything. It
doesn't matter that you already have a class called Array, you could
install as many more as you like. They would each have a different ID,
and you could tell them apart from their historical information. Since
the name of every class is unconstrained, every class effectively has
its own namespace, without having to reify the concept of "namespace" in
the developer's mental model of the system, or in the implementation of
the system.
And now for your use cases... :)
Since class names are unconstrained, supporting multiple classes
with the same name, but with unrelated development histories, is
trivial. For example, you and I both happened to choose the same name
for classes which we have developed independently, have different
message interfaces, and different slot layouts. Our classes coexist, the
compiler can compile new methods for them (with occasional
disambiguation from a person informed by historical information), and
instantiation works as always.
At the other extreme, you might want to install a previous version
of an active class that evolved over many versions, without modifying
the active class object. The system would create a class using
information from the older class edition, but give the resulting class
object a new ID, and record this with an appropriate class edition using
that new ID.
Personally, I would make some attempt to avoid both of these
situations, through discussion with my fellow authors, but I recognize
that this isn't always feasible.
For more details about Naiad, please see my blog[3].
thanks again,
-C
[1] http://netjam.org/spoon
[2] http://en.wikipedia.org/wiki/Universally_unique_identifier
[3] http://tinyurl.com/8f5zq85 (thiscontext.wordpress.com)
--
Craig Latta
www.netjam.org/resume
+31 6 2757 7177 (SMS ok)
+ 1 415 287 3547 (no SMS)
