On Jan 6, 2012, at 11:52 AM, Brendan Eich wrote:
> (This grew out of a conversation Allen and I had yesterday -- great to see it
> developed.)
>
> One thing to make clear:
>
>> ES5~EAS6: The construct has identical syntax and static semantics in both
>> ES5 and ES6, but differing semantics. For example, accessing a formal
>> parameter after an assignment to the corresponding element of the function's
>> arguments object.
>
> This is something we propose to do with completion reform, and also until
> this year for typeof null.
>
> It's clear we can't get away with changing typeof null == "null". Even with
> full opt-in, it's a runtime migration hazard (one of the five fingers of
> fate). I withdraw it -- I'm the one who proposed it in lieu of an
> Object.isObject predicate -- but I do not think we should add Object.isObject
> either.
>
> Rather, we need to rethink reflection on types in light of not only null vs.
> object, but value types/proxies. I'd rather not rush that. In the mean time,
> and for lo these 16 years (heading toward 17!), developers have coped and can
> continue to do so with typeof x == "object" && x === null or simpler (!x, x
> == null, other context-specialized combinations).
>
> In general, the latest "new syntax is its own opt-in" thinking, with Allen's
> state machine approach, means our five fingers of fate have to be small
> enough that we can get away with them. At least Mark and I believe completion
> reform (making the completion value depend on a statically decidable
> expression-statement) is the only such finger we can get away with folding
> right now.
>
>
>> If you want to explicitly force ES6 processing put a:
>> let ES6;
>
> Or (no quotes)
>
> use strict;
>
> I think we want this pragma supported, not only the string-literal
> expression-statement "directive".
If we end up with all of ES6 being a super set of ES5 strict, then I don't see
a lot value in saying: use strict;
I would think that:
use ES6; //or use version 6; etc
would better express the user intent.
BTW, I would interpret this as meaning "at least ES6" and still do feature
driven version detection of future versions using an expanded state machine.
>
>
>> at the top of the source file.
>>
>> If you want to explicitly force ES5 processing put a:
>> with (5);
>> at the top of the source file
>
> That will potentially deoptimize the top level for some engines, but maybe it
> doesn't matter. I don't expect it to catch on ;-).
Other ES5 opt-ins at the top level include:
var arguments;
function ES5(yes,yes){};
These probably won't cause any deoptimization.
However, I agree that it would be rare for someone to actually need to do this.
The intent was more to emphasize that the way you force a particular
spec-level interpretation is to code something that is unique to that
spec-level.
Allen
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
