ES4 draft: Function

Lars Hansen lhansen at adobe.com
Tue Mar 11 09:16:48 PDT 2008


> -----Original Message-----
> From: zeppieri at gmail.com [mailto:zeppieri at gmail.com] On 
> Behalf Of Jon Zeppieri
> Sent: 11. mars 2008 09:33
> To: Lars Hansen
> Cc: es4-discuss Discuss
> Subject: Re: ES4 draft: Function
> 
> 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 plain function:
>      var e = eval
>      ...
>      e(myprog)
> In both of these cases, the evaluation takes place in the 
> global environment in which the eval function is defined.
> ===

You're right, I forgot about global.eval as a workaround.

> >  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 it."

Sure, nobody argues about that per se, but I don't see the spec
as being the place to take an ideological stand about whether
global.eval is cleaner than 'new Function', if taking a stand
doesn't gain practical implementations anything at all.  The reality
is that 'new Function' and 'arguments' are available in all
implementations, they are in wide-spread use, and their use will
be propagated as long as implementations support them.  Maybe if
they are deprecated in the spec their use will see some 
decline; maybe ditto if better, alternative features are added
to the language.  I have more faith in the latter than in the
former.

I don't really care about 'new Function' as it's just another
API to functionality that will exist anyway, and 'new Function' is
comparatively clean -- I don't agree that it is significantly less
sane than global.eval.  But I and others do care about 'arguments',
so we have rest arguments and 'this function'; we do care about the
operator form of 'eval', so there's been some discussion about
whether to simply outlaw its use inside classes.  These are better
ways to make progress than paper deprecation, IMO.

--lars



More information about the Es4-discuss mailing list