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

liorean liorean at gmail.com
Mon Sep 15 16:21:09 PDT 2008


> On Sep 15, 2008, at 3:23 PM, Brendan Eich wrote:
>> I agree with Mark about callee. Just say no, if we can wean folks off
>> of it.

2008/9/16 William Edney <bedney at technicalpursuit.com>:
> Easier said than done. Not impossible (well, nothing's impossible),
> but its very problematic.
>
> There's a number of use cases given earlier on this thread. Here's
> another one:
>
> myElem.addEventListener('click', function () { doSomething();
> this.removeEventListener('click', arguments.callee, false)}, false);
>
> Could I do an assignment of the handler? Sure, but syntactically
> suboptimal, IMHO.

Once JScript has fixed the function name scope bug, you could use

    myElem.addEventListener(
        'click',
        function f(){
            doSomething();
            this.removeEventListener(
                'click',
                f,
                false);},
        false);

>> Stack backtracing deserves a separate thread.
> Agreed - although I would like to term this 'stack access', denoting
> more than just 'backtracing' capability :-). Also, this information
> should be available in any context, not just in an exception handler.
> Of course, I realize that I'm on the other end of the spectrum from
> the minimalists here :-).

There's security concerns here. You don't want to make locals
accessible from scopes that are not lexically enclosed, not even if
those locals are arguments to the function. You don't want to make
inner functions visible or ToString-able just because they are on the
call stack. You don't want to break the scope privacy, in other words.

I'm inclined to believe that the best you can do with regard to the
call stack would be to give each function a unique one-way
identification system and function calls a unique identifier as well
(so recursive calls would have the same function IDs but different
call IDs). Allow an API for the entire call stack to be exposed in
terms of a list of pairs of these two IDs. Then you can compare the
function ID to the ID of any lexically known function (or provide an
API for looking up a function object in *only* the current scope chain
by function ID), The call ID shouldn't provide any lookup facility
since we don't want to make activation frames first class objects. But
I can see that an API for traversing the call stack based on these two
IDs together should be useful. The reason for the function ID instead
function object should be clear - some of those functions may not be
lexically visible in the current scope, so shouldn't be exposed.
Calling functions from outside your own closest enclosing scope should
not be an escape mechanism for inner function objects.

That's not a strongly held opinion, however - reflection is bloody
useful in some situations, particularly for debugging.
-- 
David "liorean" Andersson


More information about the Es-discuss mailing list