Function.prototype.toString and new syntactic forms.

Mark S. Miller erights at google.com
Wed Aug 14 15:45:49 PDT 2013


For each case, we should either
a) emit a string that, when evaluated as an expression in an adequately
similar lexical context, produces a function with an adequately similar
meaning,
or we should
b) emit a string that, when evaluated as an expression in any lexical
context, fails to evaluate with an early error.

a) FunctionDeclaration, FunctionExpression, GeneratorExpression,
ClassExpression, ClassDeclaration, ArrowFunction
b?) MethodDefinition, GeneratorMethod, literal getter method, literal
setter method

For each of the members listed as #b? above, my preference would be to move
them to #a at the price of emit a string other than their source string.
But for each of them, I would find treating them as #b to be adequate.

What we should never do is emit a string which, when evaluated as an
expression, produces a value of unrelated meaning.




On Wed, Aug 14, 2013 at 3:24 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:

>
> On Aug 14, 2013, at 2:36 PM, Mark S. Miller wrote:
>
> Yes for those whose meaning is preserved by evaluating the resulting
> string as an expression. This is true for GeneratorExpression,
> ClassExpression, ArrowFunction. It isn't for MethodDefinition,
> GeneratorMethod, so they would need to stringify into something distinct
> from its source string.
>
>
> but we have nothing else that preserves 'super' references or that creates
> non-consructable functions with non-lexical this binding.  About the
> closest evaluable thing I can think of is
>
> someObject.mixin{ { <<original method source>> } )
>
> That seems like it is going too far away from the primary use case which
> is just to examine the (approximate) original source code definition of a
> function.
>
> Allen
>
>
>
>
>
>
>
> On Wed, Aug 14, 2013 at 2:13 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:
>
>> See
>>
>> https://github.com/rwldrn/tc39-notes/blob/master/es6/2013-07/july-23.md#xx-review-of-proposed-features
>>
>> http://wiki.ecmascript.org/doku.php?id=harmony:function_to_string
>>
>> The wiki proposal says the source code must be returned in the forms of a
>> FunctionDeclaration or a FunctionExpression. The meeting notes s;ay it is
>> always adequate to preserve and return the original source code.
>>
>> What about function objects defined using any of the new syntactic forms:
>> GeneratorExpression, ClassExpression, ArrowFunction, MethodDefinition,
>> GeneratorMethod
>>
>> Presumably, the last of acceptable returned forms should include these
>> new forms?
>>
>> Allen
>>
>
>
>
> --
>     Cheers,
>     --MarkM
>
>
>


-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130814/30454837/attachment.html>


More information about the es-discuss mailing list