[Harmony Proxies] Proposal: Property fixing

Sean Eagan seaneagan1 at gmail.com
Tue May 10 11:18:28 PDT 2011

On Mon, May 9, 2011 at 10:38 AM, Tom Van Cutsem <tomvc.be at gmail.com> wrote:
>> > 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.

I was not implying that these invariants should not be enforced, but
rather that if they are enforced, then non-configurable properties
should be enforced as well, as not doing so seems arbitrary and thus
confusing to users of the API.  As Allen mentioned, there are other
important invariants that are not currently enforced, and I would make
the same argument there, that either they should be enforced as well,
or that nothing should be enforced.

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

It only upholds c due to the fact that it does not allow
non-configurable properties in the first place.

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

I think the way to get b is actually through AOP (Aspect Oriented
Programming) support.  I would envision this as an AOP API that is
tightly integrated with the intercession API, having the intercession
API's "traps" serve as the "join points" "around" which the AOP API's
advice could be executed.

With regard to property fixing, if there really are use cases that it
restricts (although I don't see any), it could be made optional.  To
support this, this proposal would merely no longer throw due to a
falsey "defineProperty" trap invocation return value.

Sean Eagan

More information about the es-discuss mailing list