Classes: suggestions for improvement

Allen Wirfs-Brock allen at
Sun Jun 12 19:04:59 PDT 2011

On Jun 12, 2011, at 4:13 PM, Axel Rauschmayer wrote:

> Two observations:
> - Object.create() seems to have started something truly prototypal in JavaScript that never quite got finished. If there was a way to bring more Self to JavaScript (instead of more Java, Python, or Ruby) when it comes to inheritance, I would be all for it, but it always sounded to me like most people don’t want that.

This is much of the motivation behind the enhanced object literal and <| proposals.  They are intended to be a more usable alternative to Object.create.

> - What I find most difficult about the current way of doing inheritance is that the constructor "is" the type, while the prototype would be a much better choice.

I've been thinking a fair amount recently about prototypal inheritance in self versus what we do in JavaScript.  There are a couple things I've noted.  One is that while self started out as a deconstructed Smalltalk without classes, the evolution of the language and environment (like Smalltalk, it is hard to separate the two) ultimately took it to a place where you program in terms of abstractions that seem quite like Smalltalk classes. This seems roughly parallel to what we see occurring in both JS frameworks and We find that we need a more concrete abstraction capability then naked prototype inheritance so we  use prototypal  inheritance to createsomething that is quite similar to Smalltalk classes but quite different from Java classes).

Another thing I've noted is that in creating its abstraction facilities, self makes extensive use of multiple inheritance.  One might argue that by starting with deconstructing classes self was able to successfully incorporate multiple inheritance into its abstraction model.  This is something that was never done successfully for classical Smalltalk. I don't know how successful self actually was in this regard as I've never done any actual self programming.  However, MI seems to have been used extensive in creating the self libraries and environment. 

AT first there seems to be a big difference between how self and JavaScript approach object creation.  In self, you create an object by copying and what copying means is actually the responsibility of the object that is being copied. By default copy means make a new object that directly inherits from the object it is copied from.   Prototype objects are what most typically get copied to create new instances.

So where in JavaScript we would say:
   var p = new Person();
to create an instance of a person in self one would say:
    p = ProtoPerson copy.

and the default definition of the copy method that is inherited from the top of the inheritance hierarchy is  the equivalent (in JavaScript terms) of:
    Object.prototype.copy = function() {return Object.create(this)};

in other words copy is does prototypal inheritance in self. 

Of course, this doesn't work very well if the prototype contains non-shareable mutable state.  This is accounted for by over-riding the copy in prototype objects to appropriately deal with such non-sharable state.  For example:
  ProtoPerson.copy = function () {
      let newPerson = super.copy();   //use super similarly to what is currently proposed for;
      newPerson.siblings = ProtoCollection.copy();  // assumes siblings is a mutable, non sharable property
      return newPerson;

This is essentially the same thing you would do in a JavaScript Person constructor:
  function Person() {
       this.siblings = new Collection();
       return this

So, there is pretty much a directly correspondence between a self copy method and a JavaScript constructor function.  However, there is definitely a difference of emphasis seen here.  In self, it is the prototype object that is the focus of attention.  In traditional JavaScript it is the constructor object.

For people who want to know more about self see and particularly and 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list