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)