[Harmony Proxies] Proposal: Property fixing

Sean Eagan seaneagan1 at gmail.com
Tue May 10 12:15:04 PDT 2011

On Mon, May 9, 2011 at 1:14 PM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
>> 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 contend we should drop c.  A handler that does not maintain the specified
> invariants is a buggy handler but, in general, we can't guarantee that
> programs do not contain bugs.

But we can guarantee that programs do not contain *certain types* of
bugs, as is done with ES5 strict mode for example, and as long as this
does not preclude any reasonable use cases, then why not?

> ECMAScript is a language that generally
> favors expressiveness over early error detection.

I thought early error detection was one of the goals of ES Harmony ?

> More generally, dynamic
> languages typically defer error checking as late as possible in order to
> avoid false positives.  They check what a program actually does rather than
> what it might do.

I don't believe we have the option to check what a program actually
does in this case.  How would we validate that a proxy is upholding
the invariants of non-configurable properties throughout each
property's lifetime?

> Note that there are other explicit or implicit invariants about objects that
> are not guaranteed.  For example, the keys/enumerate traps should only
> return the names of properties whose [[enumberable]] attribute is false (at
> the time of the call) and keys should only return the names of "own"
> properties.  Yet we don't attempt to enforce that a handler correctly
> implements these invariants or disable proxy semantics upon the first
> occurrence of an action that might exercise buggy handler code.

I think while a proxy property is still configurable, semantics
related to particular values of property descriptor attributes such as
"enumerable" do not need to be enforced, because the value of those
properties can still be changed at any time, including within the
execution of another trap, such as "keys" or "enumerate".  However,
once a property is non-configurable, these values can change at any

>> 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.
> and would also properly result in a higher overhead (and hence less useful)
> facility.

As I commented before, I think AOP support is what is actually needed
here, and thus no such magic or overhead is needed for property

> I think our first priority should be the expressiveness of Proxies.  They
> need to be able to deal with all the use cases we have discussed including
> providing an faithful and efficient implementation of the existing built-ins
> and DOM.

I believe this proposal for property fixing would get us the
non-configurable properties necessary to handle some of the use cases
you are referring to.

> After we have that we can try to find situations where we can use
> the API to enforce various object invariants but even there we need to be
> selective. After all, a major use case for Proxies is to implement objects
> that in some way or another violate something about the normal invariants
> for native ES objects.

I think we should take a balanced approach as we have been to this
point.  Being able to depend on a decent set of invariants I believe
will be welcomed by both proxy providers and proxy consumers.

Sean Eagan

More information about the es-discuss mailing list