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?
>

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: <
https://mail.mozilla.org/pipermail/es-discuss/2011-December/018834.html>


> 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.

Cheers,
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130204/425aefa4/attachment-0001.html>


More information about the es-discuss mailing list