Function.prototype.toString and new syntactic forms.
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.
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.
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.
For #b?, we should also think about each "problematic case" listed at strawman:function_to_string.
See rwldrn/tc39-notes/blob/master/es6/2013-07/july-23.md#xx-review-of-proposed-features, 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?