forward-incompatible Function.prototype.toString requirement

[Michael Ficarra]

I've published an initial proposal here:
https://github.com/michaelficarra/Function-prototype-toString-revision

Feel free to add comments by opening a Github issue or pull request. I will
add this proposal to the agenda for this week's meeting.

On Fri, Apr 17, 2015 at 9:08 AM, Mark S. Miller <erights at google.com> wrote:

> On Fri, Apr 17, 2015 at 7:10 AM, Juriy Zaytsev <kangax at gmail.com> wrote:
>
>> I did some research on this just last year —
>> http://perfectionkills.com/state-of-function-decompilation-in-javascript/
>> (and originally back in 2009, when things were much wilder,
>> http://perfectionkills.com/those-tricky-functions/)
>>
>> Corresponding tests with notes —
>> http://kangax.github.io/jstests/function-decompilation/
>>
>> Cool, thanks. Lots of ancient history there. Of recent versions of
> browsers / engines, what problems do you see in arriving at ES6 conformance?
>
> Btw, I was amused to see the old Caja es5-to-es3 transpiler case in there:
>
> function f(){}; // function f() { [cajoled code] }
> var f = function(){}; // function f$_var() { [cajoled code] }
>
>
> which does raise the issue of how transpilers should cope with these
> requirements. If the source string produced does parse, what language layer
> should it be expressed in?
> (Note: Modern Caja uses SES, which usually does not transpile)
>
>
>
>> Just few days ago, I've been also thinking to add tests to ES6 compat
>> table checking these exact (ES6 introduced) "toString representation
>> requirements" from 19.2.3.5.
>>
>
> Please do! Beyond ES6 conformance, it looks like we could plausibly stdize
> something like the following for the "must not parse" case:
>
>     The function head should parse as some kind of function head.
>     The function body must match /^\s*{\s*\[[^{}\[\]]*\]\s*}\s*$/
>     i.e.,
>         { [ non-"{}[]"-text ] }
>
> The proposal would effectively commit us to never introducing a future
> syntax where this parses as a function body, addressing the issue Michael
> raises at the beginning of this thread. It would also allow reliable
> recognition of those cases intended not to parse for this reason, including
> present code recognizing future code (modulo recognizing future function
> heads :( ). Does this seem plausible?
>
> Anyone care to write an initial concrete proposal?
>
> --
>     Cheers,
>     --MarkM
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
Shape Security is hiring outstanding individuals. Check us out at
*https://shapesecurity.com/jobs/
<https://shapesecurity.com/jobs/>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150525/5796ea76/attachment.html>