obsoleting the "new" keyword

Brendan Eich brendan at mozilla.com
Tue Jan 20 11:38:51 PST 2009


On Jan 20, 2009, at 11:06 AM, David-Sarah Hopwood wrote:

> I don't see any relevant arguments in followups that would  
> contradict the
> position above.

You replied selectively -- not nice.


> The nearest thing to a relevant argument is:
>
> # The best real-world example is when implemening something in JS  
> that has
> # to match an interface across a language bridge with a reasonable  
> method
> # name such as 'delete'.

Since you deleted the rest of that paragraph, here it is again:

  In such a case you could certainly use an object initialiser or  
assignment (doesn't matter which), but you couldn't give the function  
the intrinsic name 'delete'. Named functions have their uses, not so  
much for recursive calls as for better diagnostics and less  
inscrutable pretty-printing results.


> but I think that is only plausible for names of methods, i.e.  
> properties;
> not function declarations.


This combined with deleting the relevant rest of the paragraph is a  
non-sequitur. Yes, of course, property name contexts should unreserve  
keywords. This is in ES3.1 already and not at issue, and rehashing it  
does not address the bone of contention.

The intrinsic name of a function need not have anything to do with  
property names where the property values reference the function (if  
any -- the reference could be a downward funarg, obviously of a  
different, non-reserved name). Diagnostics involving a call expression  
should use the particular property name or other expression by which  
the function was called, and do in quality implementations. But  
diagnostics and debugger expressions used within the function's body  
should be able to use the function's name, and if 'delete' is the best  
name, it ought to be allowed.

It costs next to nothing for implementations or the spec to allow  
ordinarily reserved keywords to be used after 'function', and it  
benefits some users who already make use of this ability in JS1.7 and  
up. The low cost and utilitarian benefit is the basis for  
standardization.

This is not a huge issue, but neither is it negligable -- and the  
manner in which you replied makes me want to spend more time on it  
anyway, for rhetorical hygiene if nothing else. In other words, I'm  
prepared to lose this argument and any other worth having, but only if  
you actually respond to the argument I'm making.

/be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20090120/2ac33d86/attachment-0001.html>


More information about the Es-discuss mailing list