Avoiding overloading the term “prototype”
herby at mailbox.sk
Mon Oct 22 13:40:04 PDT 2012
Herby Vojčík wrote:
> 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.
By the way, let deprecate (that is, recommend not to use) __proto__ and
introduce @parent (or other term) instead, while both having the same
> 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]].
More information about the es-discuss