links to this page:    
View this PageEdit this PageUploads to this PageHistory of this PageTop of the SwikiRecent ChangesSearch the SwikiHelp Guide
Last updated at 1:06 pm UTC on 16 January 2006
There are two main implementations of prototyping systems in Squeak:

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.

Note by Russell Allen 2005-08-24:

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:

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.