Ye olde arguments argument (was: Topic list - pending changes and issues for the ES3.1 spec)

Mark S. Miller erights at google.com
Sun Sep 14 12:30:11 PDT 2008


On Sun, Sep 14, 2008 at 11:09 AM, liorean <liorean at gmail.com> wrote:
>> El 13/09/2008, a las 2:08, Brendan Eich escribió:
>>> I hold no brief for callee.
>
> 2008/9/14 Jorge Chamorro <jorge at jorgechamorro.com>:
>> Where can I learn what's wrong with arguments.callee, what's the
>> reason why you all want to get rid of it... ?
>> TIA

The arguments object itself is often passed in order for function F to
give function G access to the argument list F with which was called.
This seemingly innocent operation should not also inadvertently
provide G with the ability to call F. F might otherwise be
encapsulated within some larger abstraction.


> It's not callee that that everyone wants to get rid of. It's the
> arguments object itself.

Yes and no. Come Harmony strict, we will at least deprecate
'arguments'. We would certainly like to get rid of 'arguments' in
strict mode.   However, we're stuck by the following constraints:

* In the ES3.1 timeframe, we won't yet have optional and rest
parameters (spread, etc...), so we can't prohibit arguments in
ES3.1-strict.
* Correct ES3.1-strict programs should remain correct ES-H-strict programs.
* While we have left open the option of introducing a distinct
ES-H-stricter, in order to enforce stronger constraints, we should
desperately avoid exercising this option without compelling reason, as
every mode switch and pragma contributes to a combinatorial explosion
of cases and a testing nightmare. Killing 'arguments' by certainly not
reason enough by itself to introduce such a distinction.

Since we can't get rid of 'arguments' come ES-H-strict, we should do
what we can to clean it up in relatively painless ways for
ES3.1-strict. From the reactions on es-discuss so far, it seems like
killing arguments.callee in ES3.1-strict is painless enough. I think
we'll proceed on that basis.

After ES3.1, I think I like the idea of providing stack trace
information in a standardized way on Error objects. Anyone care to
make a proposal?

-- 
    Cheers,
    --MarkM


More information about the Es-discuss mailing list