callable objects ?

David Bruant bruant.d at gmail.com
Wed Apr 18 14:06:09 PDT 2012


Le 18/04/2012 19:48, Brendan Eich a écrit :
> Mainly the own-only restriction seems less-good compared to how, e.g.
> proxy traps or accessors are found, via full prototype-based delegation.
I agree with your point.

However, I'd like to restate that interaction between proxies and
private names as currently design is unusable:

    var callName = import @call;

    var target = {
        [callName]: function(){console.log('yo')}
    };

    var p = Proxy(target, {});
    p(); // throws exception because the proxy is reported as not having
a @call property

In the get trap of the proxy, the @call private name is transformed into
its public conterpart. When, by default, the trap forwards to the
target, the public alter-ego is coerced into a string. Consequently, the
actual @call property of the target isn't found.


> Are some of these proposed and novel base-level traps better off
> own-only, in spite of this general rule?
Did you mean traps or private properties? Assuming private properties.
The precedent here is the different non-standard pseudo-properties.
For __noSuchMethod__, it is inherited which is probably what is
expected. I tested with:
===
var o = {};
o.__noSuchMethod__ = function(n){
    console.log('__noSuchMethod__ call', n);
}

o.a();

var o2 = Object.create(o);

o2.c()
===

__defineGetter__ and __defineSetter__ only made sense as if considered
as own properties I think.

__proto__ would make sense as an own property reflecting directly
objects own internal [[Prototype]] property (which seems to be V8
behavior). Reality and security concerns make it a different story

Besides specific cases of things that touch the specific aspects of
singular object, I agree that inheriting is better.

David


More information about the es-discuss mailing list