The entire concept of {{ ... }} irks me, and probably quite a few
others. This would add a level of syntax complexity and confusion
non-intuitive to most developers.
Object literal {{ foo : bar}}?
function(){{...}} ?
if(){{
...
}}
else {{
...
}}
switch()? with()? Imagine JSON with these rules. thats abhorrent. I
understand the concern with scoping but this would be too far of a shift
to be considered I would hope.
>>I would like an arrangement that combines opt-in and explicit
>>block-type notation.
>>
>>A block is either scoping or non-scoping:
>>
>> function Test (List)
>> {{
>> if (Debugging)
>> {
>> const DbName = "Test";
>> var Counter = 5;
>> }
>>
>> for (var Num = 0; Num < List.length; ++Num)
>> {{
>> var Text = List [Num];
>> Result += Text [3];
>> }}
>> }}
>>
>>Double braces {{ }} indicate a scoping block, single braces
>>{ } indicate a non-scoping block. A declaration binds the
>>name to the nearest surrounding scoping block {{ }}. A non-
>>scoping block { } can never bind a name. All the keywords
>>var, const, function etc. behave in exactly the same way
>>in this regard.
>>
>>You opt in by using double braces at a point where a block is
>>possible. At the outermost level of the source text the old
>>rules apply. If you use { } the old rules remain in force.
>>If at any point you surround a block with {{ }}, then inside
>>this block double braces {{ }} are always scoping and single
>>braces { } are never scoping.
>>
>>You can choose freely between scoping and non-scoping block
>>wherever this is supported by the standard. When a context
>>requires a certain type of block you must use the correct
>>markings, else a syntax error is thrown. There is no hidden
>>automatic correction, your notation must be correct. (But
>>only when you enable this.) This is so a programmer who
>>doesn't know the requirement is told. No hidden semantics!
>>
>>So if the language requires that all function blocks must
>>be scoping, then when this is enabled you can only mark
>>function blocks with {{ }}. And if the language can't
>>deal with a certain construct written in a non-scoping
>>block, then you can only put this construct in blocks
>>that you mark {{ }}.
>>
>>If peculiar rules are needed, they won't cause surprises if
>>they become opt-in together with the syntax change. But I'm
>>hoping that the above, together with clear compilation error
>>messages, can minimize peculiarities and make things clear
>>and simple.
>>
>>Note that old browsers can compile source that uses this
>>syntax. However the meaning may be different. Hopefully
>>with suitable preparations and restrictions a linter or an
>>ECMAScript implementation can check the intended meaning
>>and analyze whether the program will have this intended
>>meaning when compiled in an old browser.
>>
>>One unknown factor is that I don't know if the proposed
>>markings are sufficient for opt-in, or if something else
>>is required to avoid incompatible ambiguity.
>>
>>The scoping rules of ECMAScript are becoming very complicated.
>>The behavior of the keyword "function" varies so much among
>>vendors that it can't be standardized,
>>https://mail.mozilla.org/pipermail/es3.x-discuss/2008-July/000280.html
>>"var" and "const" have now been specified to behave each in
>>its own way, and "let" requires many paragraphs of explanation.
>>
>>I think the above can offer simplicity and clarity.
>>
>>Ingvar
_______________________________________________
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
