Herby Vojčík herby at mailbox.sk
Fri Mar 16 01:34:59 PDT 2012

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


More information about the es-discuss mailing list