[Harmony Proxies] Proposal: Property fixing

Tom Van Cutsem tomvc.be at gmail.com
Mon May 9 08:38:31 PDT 2011


>
> > I do see benefit in this proposal as an aid for proxy writers to develop
> > more well-behaved proxies. But for that purpose it seems that this
> proposal
> > can be fully written as a Javascript library layered on top of the
> existing
> > API.
>
> But couldn't the same be said of the "fix" trap, frozen prototype, and
> frozen typeof for proxies ?
>

As for the fix trap: there needs to be some way for a proxy to react to
freeze|seal|preventExtensions, even with your proposed extension.

As for frozen typeof: there have been proposals in the past of adding an
additional argument to Proxy.create to configure the proxy's |typeof| value
(still operating under the restrictions of ES5 11.4.3). If this
configurability turns out to be necessary in certain scenarios, I'm sure it
will be reconsidered.

As for frozen prototype: despite non-standard __proto__, the current
consensus is to move away from mutable prototypes, not to add standardized
features to support it.


> Also, since proxies are not allowed to advertise their properties as
> non-configurable, without something like this proposal proxy
> transparency cannot be achieved.  With the current API, one could
> implement a "Proxy.isProxy" function as follows...
>
> Proxy.isProxy = function(objectOrProxy) {
>  let unlikelyPropertyName = "_ at _*_&_%_+_!_";
>  Object.defineProperty(objectOrProxy, unlikelyPropertyName, {});
>  return Object.getOwnPropertyDescriptor(objectOrProxy,
> unlikelyPropertyName).configurable;
> }
>

Good point. As recently pointed out by Allen, the design point of not
allowing proxies to emulate non-configurable properties is still
controversial. I have always felt it to be an odd restriction, but I don't
have a good alternative that doesn't break |configurable|'s implied
invariants. The sweet spot that we seem to be looking for is an API that:

a) allows non-configurable properties to be emulated,
b) while still allowing access to these properties to be intercepted (e.g.
for logging/tracing),
c) and upholding the invariants of non-configurable properties.

The current API doesn't allow a, but upholds c (b is not an issue).
Your proposed extension would allow a, but not b, and still uphold c.
If one is willing to drop c, it's easy to get a and b by simply removing the
check for configurable:true from the current API.

I can think of an API that satisfies all three by e.g. extending your
proposal such that access to non-configurable properties still triggers the
get trap, but ignores its result, making the proxy more like a chaperone in
Racket <
http://docs.racket-lang.org/reference/chaperones.html?q=chaperone#(tech._chaperone)>
(chaperones may intercept operations, but are not allowed to influence the
result of the operation).

I'm worried though that such additional magic, tucked away in the proxy
implementation, can make for a very difficult-to-understand overall API.

Cheers,
Tom


>
> Thanks,
> Sean Eagan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110509/c2e2200f/attachment.html>


More information about the es-discuss mailing list