On 16 April 2015 at 14:34, Frankie Bagnardi <f.bagna...@gmail.com> 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.
/Andreas
>
>
> On Thu, Apr 16, 2015 at 2:56 AM, Andreas Rossberg <rossb...@google.com>
> wrote:
>
>> On 16 April 2015 at 11:34, Michael Ficarra <mfica...@shapesecurity.com>
>> 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
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
