Proxying Native Objects: Use case

Tom Van Cutsem at
Mon Feb 4 11:48:32 PST 2013

2013/1/31 François REMY < at>

> Is a kind of __noSuchProperty__ really impossible to support for native
> objects? Given the fact you didn't respond I guess this is a no, but is
> there any valid reason you won't allow it? Performance-wise Gecko already
> supports __noSuchMethod__ so a properly standardized solution should be
> possible, right?

Hi François,

I don't know if native objects have a mutable [[Prototype]] (by assigning
__proto__) but if they do, then one solution might be to have your native
objects inherit from a proxy. The proxy should then be able to intercept
all missing properties, as I once sketched: <>

> I'm a bit under the impression that proxies were created because they were
> more powerful than __noSucXXX__, and now I'm under the impression that we
> end up in a situation that's much less powerful in the case of polyfills...
> and polyfills were one of the very good reasons to support proxies in the
> first case.

As David argued, turning arbitrary existing objects into proxies is a no-go.
The main reason why Proxies gained any traction in TC39 in the first place
was that they introduce a new, distinct object type, without impacting the
semantics or performance of existing objects.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list