Catch-all proposal based on proxies

Mike Samuel mikesamuel at
Mon Dec 7 18:59:33 PST 2009

2009/12/7 Tom Van Cutsem <tomvc at>:
> On Mon, Dec 7, 2009 at 4:44 PM, Mike Samuel <mikesamuel at> wrote:
>> Under "This avoids questions like:",
>> does the proposal also avoid
>>   5. Can property trapping be defined on host objects
> Yes, it does avoid this issue. One cannot trap properties of host objects.
> But one can define a proxy that redirects property access to a host object.

How much of a strength is the host-object agnosticism of this approach?
How much work it would be on people's favorite interpreters to get
host objects working with an imaginary alternate proposal that added
catchAlls o an object after creation, i.e.
    Object.defineCatchAll(myHostObject, ...)

>> "The Type of a Proxy"
>> Why does the type change upon fixing?
>> Is it an error to pass a value v s.t. (typeof v !== 'function') to
>> Proxy.createFunction?   Specifically RegExps?
> The "applyTrap" and "constructTrap" arguments to Proxy.createFunction should
> be callable, so anything with an internal [[Call]] method will do.

Ah ok, I missed the applyTrap on first read and got confused by the
Invoke vs Get+Call stuff into thinking that apply was handled as a
method of undefined.

>> "Equality:"
>> Would defining a Proxy.proxies(proxy, obj) that returns true iff obj
>> was the argument to Proxy.create{,Function} that created proxy allow a
>> useful level of equality checking?  That would allow limited checking
>> by code that already possesses a handle to the underlying object
>> without potentially leaking an underlying object to a bad proxy.
> For this proposal it does not make sense to ask whether a proxy proxies a
> particular object 'obj'. However, it does make sense to ask something
> similar like "Proxy.isHandledBy(proxy, handler)", which would return true
> iff 'handler' equals the proxy's internal handler attribute. Such a method
> cannot be defined by user code, since given a proxy it's impossible to get a
> reference to its handler. If there's a good use case for providing such a
> function, it could be added.

I can't think of any compelling use cases of the top of my head.

>> "[[DefaultValue]] (hint)"
>> "[[Class]]"
>> The rule for "[[Class]]" means that it's possible to create proxy an
>> array in every way but that the isArray test used by common libraries
>> cannot be spoofed:
>>     '[object Array]' !==
>> What is the proper behavior here?
> This is a good point. Our current proposal does not allow proxies to
> influence the value of their [[Class]] attribute, so the above "isArray"
> test would fail for a proxy trying to emulate an array.

I don't think this is a defect.  But I think one side-effect of
proxying and/or iterators/generators would be a sudden profusion of
array like objects so I started a separate thread to discuss whether
it's worth weighing in on what is array-like and what is not.

> Cheers,
> Tom

More information about the es-discuss mailing list