I have another concern about the potential interactions between the proposed name property and toString. Apparently, there is a known use case of eval'ing the result of toString'ing a function in order to create a new function. If we assign synthetic names such as "get_foo" or "set_foo" to syntactically defined getter/setter functions or allow a user to associate a name with an anonymous function which then appears in the toString representation will mean that eval will parse the toString result as a FunctionDeclaration rather than a FunctionExpression. For non-strict evals, that means that the synthetic name will get added to the Declaration Environment of the eval. Note that for indirect evals, the Declaration Environment is now the Global Environment but even for nested eval this possibility seems like a hazard that that most uses are not dealing with.
Of course, this issue already exists in ES3 for syntactically named functions and functions that are internally assigned the name "anonymous" so maybe these additions aren't actually making things much worse. However, this concern along with Maciej's latest suggestions about Function.create pushes me further in the direction that we should hold off on adding a function name property in ES3.1. We still might want to consider enhancing the specification of toString to explicitly address the naming of functions created other than by a FunctionDeclaration/FunctionExpression. However, since some of the same issues arise there I'm inclined to leave it as implementation defined for ES3.1. Allen _______________________________________________ Es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
