Brendan Eich wrote:
Herby Vojčík wrote:
I am probably writing densely and you had little time. I have written
at the beginning of 1.:
'class ...}' as a sugar for 'function ...}.prototype'
(I put similar texts describing the idea to the header of 2. and 3. as
well)
I get it, but it is not coherent.
A function binding form in JS can be refactored as an expression, and it
evaluates to the same result that an Identifier PrimaryExpression
denoting the bound name evaluates to: the function object. Not its
.prototype when used as an expression, the function itself when denoted
by its name.
This is what I meant by incoherent. You can make it "consistent" by some
criteria but it does not match function declarations vs. expressions and
that is a problem.
I do not understand your concern. If you _define_ the class keyword
works same as function keyword in all aspects except the completion
value (that is also return value of class expression) return the
prototype, what incoherency is there? It behaves consistently all over.
"does not match function declaration vs. expression" is a matter of
interpretation. I can say it matches because:
- same as function declaration, class declaration defines function with
supplied name and body, able to [[Construct]] and with prototype object
created appropriately
- same as function declaration/expression, class
declaration/expression's comp[etion value is well defined, in function
case it is always the function, in class case it is always the
function's prototype.
It is explicitly written that "since 'var foo = (function bar() {...})'
put bar function into foo, it is compulsory for 'var foo=(class bar()
{...})' to also put bar function into foo, because both are
function-like constructs"?
/be
Herby
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
