Re: E4H and constructing DOMs

Ian Hickson wrote:
> On Thu, 7 Mar 2013, Rick Waldron wrote:
>> E4H is a language level syntax extension that appears to duplicate the
>> functionality provided by Template Strings, while restricting usage to a
>> web/DOM-centric concept (CORS same-origin or Worker context)�effectively
>> creating a "version". It also uses one of the remaining unambiguous
>> ascii characters "@". Granted, it's an interesting experiment, but
>> Template Strings are capable of "all this and more".
>
> To be fair, unless they've changed quite substantially since the last time
> I saw them, quasis don't do the one thing that is E4H's whole point,
> namely compile-time syntax checking.

Allen's right, partial evaluation is relatively easy for template 
strings. If that's the only issue, we should get on with implementing it 
and relieve the concern.

Some of us who missed the E4H threads are likely to be surprised, 
because E4X failed, and not because of the 'X'. Not wholly because of 
design flaws and spec bugs, either, although those were severe.

One flaw we had to patch outside of the spec: preventing XML data theft 
by loading an XML resource as a JS+E4X script. We banned at compile time 
an E4X XML literal from being the entire Program (ECMA-262's grammar 
goal non-terminal).

I'd like to hear more about the security concerns with template strings. 
I couldn't find that at a glance among the three links Ojan footnoted.

Anne hit the nail on the head at 
http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/1076.html 
-- E4X was rejected by Ecma TC39, E4H face that same fate. Given 
template strings, is this really a necessary fight to pick and try to 
win with "who will implement first?" dares?

/be

Received on Thursday, 7 March 2013 19:24:11 UTC