Re: Avoiding overloading the term “prototype”

Claus Reinke claus.reinke at
Wed Oct 24 12:00:16 PDT 2012

> When I explained __proto__ at JSConf, the first question was: “How
> is __proto__ better than the ‘prototype’ property that all constructors
> already have?”

|On the other hand, Axel's point is taken: the subject of 'prototype'
|is confusing. But this is only partly terminology; much of the problem
|is built in to the system. The operation of 'new' is weird, the
|flexibility allowed by __proto__ is unsettling and Object.create()
|completes the puzzle.

Even to those familiar with the concept of prototypical programming,
the JS version is confusing: in Self, "__proto__" would have been a
"parent slot", the content of ".prototype" would have been a "parent
object", while Self's idea of a "prototype" would have been an
ur-object from which a new instance was copied; both copying and
ur-object are implicit in JS constructors.

With __proto__ standardized, there is less need to refer to things
outside the language, such as [[Prototype]]. That also alleviates the
issue of overloading and re-interpreting the word "prototype".

We could look for a set of equations (involving code fragments
instead of spec language) to express 'prototypical inheritance
on a t-shirt/on one slide'. Something like (cheating a little, where
suitable syntax seems to be missing:-(

0    Constructor.__proto__ === Function
      Constructor.prototype.constructor === Constructor

1    ( new C(...args) ).__proto__ === C.prototype

2    new C(...args) === C.apply( { __proto__ : C.prototype } , ...args )

3    Object.create( p , {} ) === { __proto__ : p,}

Expressing recursive selection is trickier (eg, it would be good to
be able to split an object into __proto__ and __proto__-free own
properties, to create objects from properties, and to have

4    { __proto__ : p,}[m] ===
         { __proto__ : p, }.hasOwnProperty(m)
         ? ( ({ m: v }) => v )( { } )    // select directly
         : ( p===null ? undefined : p[m] )        // try up the chain

If we can flesh out this idea, it could become a cheat sheet that is
easier to digest than the formal language of the spec and could
support attempts to explain the ideas in informal language.

Languages like Lisp, Smalltalk and Prolog could express their core
on a "page", via meta-circular interpreters. How many pages for JS?-)


More information about the es-discuss mailing list