Russell Allen's code creates objects which are their own class (ie obj class == obj). This enables them to encapsulate their own behavior. To save space, objects can share their behavior by delegating it to another prototype (essentially they are instances). This is automatic.
Neither of these two implementations really makes me happy. The original code still keeps the class/instance distinction, but makes it more flexible and hidden. You will still need to make decisions about what goes in the Behavior (at the moment some minimal reflective capabilities) and what goes in the Prototype. My new code is (imho :) an improvement, but suffers from at least two serious problems.
The first problem is technical - I think that I have prematurely optimised to save space (smaller objects) and have accordingly sacrificed speed.
The second problem is more philosophical. Underlying both my code and Hans-Martins lurks the idea that an object is 'really' just a dictionary of slots, some of which are methods. This approach comes partly from self, but is found in other languages such as python and http://www.iolanguage.com (which is a wonderful language, btw).
I don't think that objects are 'really' lists of named slots, although that may be a useful way to look at them. There is no point in forcing objects to comply with one single mental model of what they should be. They should be able to encapsulate their own structure.
What does this mean? Well, my current thoughts are:
eliminate lightweight prototypes (ie instances) for now. We can bring them back as an optimisation later if we want
get rid of automatic slot accessors (bringing back the ability to address instance variables using var := something syntax)
On this base, I want to try to maybe distinguish between different types of variables - not based on instance or class but between 'internal' variables and 'external' variables. Maybe Andreas Islands would integrate well with this.
