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/ 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. -- kangax On Thu, Apr 16, 2015 at 4:33 PM, Mark S. Miller <[email protected]> wrote: > I agree with all this. Let's gather current precedent across JS > implementations of function printings are not and should not be parseable > and see if we can extract a clear spec that is consistent enough with > current reality. > > > On v8: > > Object > function Object() { [native code] } > > Object.bind(Object) > function () { [native code] } > > On SpiderMonkey: > > Object > function Object() { > [native code] > } > > Object.bind(Object) > function Object() { > [native code] > } > > On JSC: > > Object > function Object() { > [native code] > } > > Object.bind(Object) > function Object() { > [native code] > } > > > Looks promising so far! Anyone care to do a more complete investigation > and write up an initial proposal? > > > > > On Thu, Apr 16, 2015 at 7:13 AM, Frankie Bagnardi <[email protected]> > wrote: > >> I just meant that it seems confusing that it can both produce a >> FunctionExpression >> and "return a string for which eval will throw a SyntaxError exception." >> >> I didn't mean to highjack this thread; the concern in the original email >> is noteworthy. There should be recommended syntaxes which future versions >> of the spec agree not to break, including current browser implementations. >> This gives any future engines, or modifications to current engines a >> clearly defined acceptable way to format these strings. >> >> This also gives libraries which parse functions at runtime (despite how >> good of an idea this is) quick bail cases without using eval. Examples of >> this are angular and require.js. >> >> >> >> On Thu, Apr 16, 2015 at 6:55 AM, Mark S. Miller <[email protected]> >> wrote: >> >>> >>> >>> On Thu, Apr 16, 2015 at 6:36 AM, Andreas Rossberg <[email protected]> >>> wrote: >>> >>>> On 16 April 2015 at 14:34, Frankie Bagnardi <[email protected]> >>>> wrote: >>>> >>>>> The part that sticks out to me is... toString on functions currently >>>>> throws a syntax error when eval'd for non-named functions. Tested in >>>>> chrome: >>>>> >>>>> var f = function(){ return 1 };eval(f.toString()); // SyntaxError >>>>> // becausefunction(){ return 1 }; // SyntaxError >>>>> // but, force an expression: eval("(" + f.toString() + ")") // >>>>> essentially clones f >>>>> >>>>> >>>>> This... is confusing in my opinion. >>>>> >>>> >>>> Yeah, the spec says: >>>> >>>> "The string representation must have the syntax of a >>>> FunctionDeclaration FunctionExpression, GeneratorDeclaration, >>>> GeneratorExpression, ClassDeclaration, ClassExpression, ArrowFunction, >>>> MethodDefinition, or GeneratorMethod depending upon the actual >>>> characteristics of the object." >>>> >>>> which is weird. First, it doesn't really make sense, because whether >>>> something originates from a declaration vs expression isn't a >>>> "characteristic of the object". Second, making it return different >>>> syntactic classes in different cases is not particularly useful for your >>>> case. >>>> >>>> But then again, using the result of f.toString as input to eval is A >>>> REAL BAD IDEA anyway; toString should only be used for diagnostics, not >>>> programmatically, because that is meaningless in general. So I personally >>>> don't mind the friction. >>>> >>> >>> Disagree. The purpose of this change in toString spec from ES5 is >>> primarily to support pass-by-copy closed functions. The intent was that it >>> always work to evaluate them as expressions, i.e., with the surrounding >>> parens. >>> >>> http://wiki.ecmascript.org/doku.php?id=harmony:function_to_string >>> http://wiki.ecmascript.org/doku.php?id=strawman:concurrency#there >>> >>> >>> >>> >>>> >>>> /Andreas >>>> >>>> >>>> >>>>> >>>>> >>>>> On Thu, Apr 16, 2015 at 2:56 AM, Andreas Rossberg <[email protected] >>>>> > wrote: >>>>> >>>>>> On 16 April 2015 at 11:34, Michael Ficarra < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> ES2015 section 19.2.3.5 (Function.prototype.toString) places four >>>>>>> restrictions on the output of Function.prototype.toString, one of which >>>>>>> is >>>>>>> >>>>>>> If the implementation cannot produce a source code string that meets >>>>>>>> these criteria then it must return a string for which *eval* will >>>>>>>> throw a *SyntaxError* exception. >>>>>>>> >>>>>>> >>>>>>> What is a SyntaxError today may not be a SyntaxError tomorrow. How >>>>>>> can an implementation return a string that will satisfy this >>>>>>> requirement in >>>>>>> the future when the language has added new syntax? Does the committee >>>>>>> have >>>>>>> a SyntaxError recommendation that can be added as a non-normative note >>>>>>> to >>>>>>> that section? >>>>>>> >>>>>> >>>>>> In the (probably unlikely) case that the language changed that way, >>>>>> and an affected implementation adopted that change, then it would simply >>>>>> have to change its toString implementation accordingly at that point. I >>>>>> don't see a problem there. >>>>>> >>>>>> /Andreas >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> es-discuss mailing list >>>>>> [email protected] >>>>>> https://mail.mozilla.org/listinfo/es-discuss >>>>>> >>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> es-discuss mailing list >>>> [email protected] >>>> https://mail.mozilla.org/listinfo/es-discuss >>>> >>>> >>> >>> >>> -- >>> Cheers, >>> --MarkM >>> >> >> > > > -- > Cheers, > --MarkM > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
