Proxying Native Objects: Use case
Tom Van Cutsem
tomvc.be at gmail.com
Mon Feb 4 11:48:32 PST 2013
2013/1/31 François REMY <francois.remy.dev at outlook.com>
> 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?
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...
More information about the es-discuss