On Jan 6, 2012, at 1:35 PM, Axel Rauschmayer wrote:
>> The issue is *how* the spec and implementations decide what is supported,
>> and when to raise an error on new syntax mixed (after) old non-strict code
>> (e.g., 'with').
>
>
> Ah, OK. I thought that one would be able to lump together ES5.non-strict and
> all prior ES versions on one hand and ES6 and ES5.strict on the other hand.
Notice that two of the four states contain possible outcome
terminate with Error: invalid combination of ES5 and ES6 features
These are the states labeled ES5 and ES6.
It should be clear that you need more than two states to judge whether a given
hunk of code is ES5 non-strict (or lower) -- the default unversioned <script>
JS we know today -- or ES5-strict or higher. To have only two states in the
machine, you would need version-based opt-in.
But don't worry about counting states. Count minimal or even non-minimal
"modes" if you like ;-).
> But it makes sense that even if developers (engine users) are presented with
> something simple, implementors have to take care of many more details.
A point that I flog often. The few and skilled implementors should take some
complexity on behalf of the whole user base, provided that complexity in
implementation and specification saves the bulk of users enough by simplifying
migration and adoption.
IMHO we are onto something good here. The complexity for the implementors does
not too bad (I'm looking at it right now for SpiderMonkey), and the user-facing
wins are huge.
/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
