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
behaviour.
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
Herby
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
