A random collection of ES4 draft spec surprises and thoughts

[Brendan Eich]

On May 26, 2008, at 11:06 AM, Mark S. Miller wrote:

> Doing so breaks the subset
> relationship between JSON and EcmaScript. (Granted, we also need to
> acknowledge that this relationship is currently broken by Firefox.

Not Firefox -- both Mozilla JS implementations (SpiderMonkey and  
Rhino) support __proto__ (readably -- let's ignore the writable case).

ActionScript also had read-only __proto__ in at least one of its  
versions. I'm not sure if it still does in AS3.


> But
> part of the purpose of standards is to encourage browser vendors to
> repair their implementations.)

If it ain't broke, don't fix it.

If I recall correctly (and I'm sure someone will set me straight  
otherwise), JSON is not compatible with ES3 -- Unicode non-BMP  
character handling differs. Trying to force a subset relation from  
JSON to ES4 is not going to fly if JSON is not a subset of ES3. What  
matters is the intersection being "big enough", and hard cases like  
__proto__ or other mangled names do not much matter.


> * What's ">=="? I've never seen that before.

A typo?


> * What does the "var" attribute mean inside an object literal?

Same as elsewhere: it makes a fixture.


> * Now that we have let-at-the-new-var, i.e., a properly lexically
> scoped letrec behavior, do we still need the "let" expression and the
> "let" comprehension? Can we kill these?

(I'm not sure what you mean by "let" comprehension, but :) No, they  
have different use-cases that deserve attention.


> * Why does the grammar allow function calls in
> LeftHandSideExpressions. For example, what's the meaning of
>
>     foo(a)++
>
> ?

Notice how ES1-3 grammars also produced such sentences. We do not use  
a bottom-up grammar to make such sentences not parse, and neither do  
real implementations.

Indeed, IE JScript (for VBScript compatibility) long ago added  
support for "Reference" type return values from certain native ("host  
object") methods. This enabled domNode.item(i) = j, e.g. SpiderMonkey  
added support because someone embedding its open source wanted to  
support code written for JScript.

Thus the ES1-4 grammars can produce these expressions, but they are  
ruled out semantically for some or all kinds of objects. See ES3  
11.3.1 and 11.13.1, then 8.7.1 step 1; also 16 fourth bulleted item.


> * Why does delete operate on a PostFixExpression rather than a
> LeftHandSideExpression? What's the meaning of
>
>     delete x++;
>
> ?

This looks like a bug to me: ES3 has the production

UnaryExpression : delete UnaryExpression

But in any case, LeftHandSideExpression is not compatible. Jeff  
should weigh in here.


> * I thought "like" was dead. How did it get revived?

We removed "like" from the type system. It's still a binary operator,  
and there is sugar for enforcing like relations on arguments and  
return values.


> * What is
>
>    "super" "(" Arguments ")"
>
> ? Last I heard, ES4 only has single implementation inheritance, so why
> allow "super" to be qualified?

Not sure what you mean by "qualified", but super can be *called*.


>            Core Semantics
>
> * I'm pleasantly surprised to see that the prototype reference (which
> I take to be the same as the ES3 internal [[Prototype]] property) is
> said to be immutable. Does this mean that we will be able to consider
> the following behavior buggy (I hope so):
>
>     var x = {};
>
>     var y = {};
>
>     x.__proto__ = y;
>     [object Object]
>
>     y.foo = 3;
>     3
>
>     x.foo
>     3

If the property is read-only then of course assignment to a property  
of y can't affect x. Under 'use strict', the attempt to set the read- 
only __proto__ property throws.


> * What namespace is "__ES4__" defined in?

The public (compatibility) one -- hence the ugly __ bracketing, to  
minimize chance of collision.

I left a few questions for others to answer ("rib" is defined in at  
least one place in the draft specs I reviewed).

/be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20080526/c9e3dbe8/attachment-0002.html