Avoiding overloading the term “prototype”

Herby Vojčík herby at mailbox.sk
Mon Oct 22 13:30:01 PDT 2012

Axel Rauschmayer wrote:
> This probably comes across as being overly obsessed with details, but I
> think that clear terminology matters. It would be nice if we could avoid
> the term “prototype” being overloaded in ECMAScript. It still trips up
> JS beginners: When I explained __proto__ at JSConf, the first question
> was: “How is __proto__ better than the ‘prototype’ property that all
> constructors already have?”
> How about the following?
> - proto (of an obj): the “fallback” object, access via __proto__
> - prototype (of a type): value of Constr.prototype

Well, this bugged (and bugs) me long ago; that neither .prototype nor 
__proto__/[[Prototype]] is Prototype (GoF or Self way).

Beginners were always confused - I ended up calling [[Prototype]]
"parent" or "ancestor" and .prototype "shared instance traits", "shared 
instance parent" or something like that (the term did not stabilize).

I would _really_ glad, if the terms would be changed so that they will 
be truer, that is, none of those two things would be called proto(type). 
There is legacy reason why one is access via 
__proto__/Object.getPrototypeOf() and the second via .prototype, but it 
would be awesome if they get the names which really would grasp their 
real meaning.

I was just too scared to bring it on, because it seemed that this is set 
in stone.

> Not entirely happy with this, but it’s better than using the same word
> twice. And it corresponds to how one would pronounce the property names
> (modulo “dunder”). If the above is OK then we could rename [[Prototype]]
> to [[Proto]].
> Axel


More information about the es-discuss mailing list