ES4 draft: Function
jaz at bu.edu
Tue Mar 11 08:32:44 PDT 2008
On Tue, Mar 11, 2008 at 10:49 AM, Lars Hansen <lhansen at adobe.com> wrote:
> I think there are three points to be made here. The first is
> that the Function constructor provides functionality that
> eval does not, namely, creating new functions that are closed
> in the global environment only. Erik made the
> argument that this is sometimes useful; I agree.
Doesn't global.eval() meet this requirement? From the overview document:
ES4 additionally defines eval as a function bound in the global
environment that can be called indirectly
through that environment (e.g., as window.eval(s) in a web browser) or
whose value can be read and
passed around, stored in other variables and so on, and called as a
var e = eval
In both of these cases, the evaluation takes place in the global
environment in which the eval function is
> The second point is about deprecation. TG1 has had a difficult
> time with deprecation in general. It is not clear that
> deprecation means anything on the web, except /maybe/ in the
> very long term. The fact that we deprecate something has
> no bearing on existing content, and new engines will need
> to support old behavior.
Deprecation isn't solely (or even primarily) for the benefit of
implementors. It tells the programmer: "This probably isn't what you
want, and even if it does what you want, there's a more sane way to do
What does new Function() get you that eval doesn't (taking into
consideration global.eval())? For the most part, it's just
syntactic... well, not sugar, because it doesn't actually result in a
cleaner syntactic construction. 'Syntactic salt' still suggests some
kind of enhancement... I'd call it a syntactic booger.
To the extent that it isn't just a special case of eval(), it's
useless. You could, for example, define a subclass of Function that
might do something potentially useful. I notice that you can't
instrument the normal call functionality, since the instance version
of meta::invoke() is final, but you might be able to instrument
apply() for some potentially useful debugging purpose. But to make
use of it, you would need to construct your functions using 'new' and
incur the enormous performance penalty -- not to mention the fact that
since all functions so created are closed in the global environment,
it's completely worthless for functions that need to close over
> So though TG1 finally (on my
> insistence) deprecated the arguments object, it was with
> a shrug, and it would be surprising to me if the deprecation
> clause makes it into the final spec, as it has no real impact.
> (I actually wanted to remove the arguments object from ES4
> so that ES4-only implementations would not have to implement
> it at all, to be replaced by rest arguments and "this function".)
> The third point is, why deprecate that particular functionality?
> It's not like it costs much at all in terms of spec space or
> implementation complexity. Eval already requires hooks into a
> run-time compiler, which is where the heavy lifting goes.
Again -- this isn't for the benefit of implementors.
More information about the Es4-discuss