[Harmony Proxies] Proposal: Property fixing

Tom Van Cutsem tomvc.be at gmail.com
Sun Jun 19 08:43:00 PDT 2011

2011/6/17 David Bruant <david.bruant at labri.fr>

> **
> Symetrically to the forwarding of defineProperty, maybe that
> getOwnPropertyDescriptor could be forwarded too (requires to call the
> getOwnPropertyDescriptor trap for non-configurable properties) and the
> return value could be used to redefine writable on the proxy fixed property
> if necessary.

Yep, trapping getOwnPropertyDescriptor on fixed properties seems to close
the loop.

However, I find it strange that the return value of getOwnPropertyDescriptor
would actually implicitly side-effect the fixed property of the proxy. I
naturally think of defineProperty as a side-effecting trap, not so for
getOwnPropertyDescriptor. Perhaps it should only check the return value for
consistency with the fixed descriptor, without side-effects.

One can still achieve 'synchrony' between a target's descriptor and the
proxy's fixed descriptor by explicitly setting the property in the
getOwnPropertyDescriptor trap (at least then the side-effect is explicit):

// assume 'name' already refers to a fixed property within 'proxy'
function getOwnPropertyDescriptor(name, proxy) {
  var desc = Object.getOwnPropertyDescriptor(this.target, name);
  if (desc && !desc.configurable) {
    // desc is non-configurable, redefine it on the proxy to keep it in sync
    Object.defineProperty(proxy, name, desc); // can only change
writable:true into writable:false
  return desc; // proxy will test whether 'desc' is consistent with the
fixed descriptor stored in 'proxy'

> - Issue with a proxy saying that an inherited property is a
>> non-configurable property (getPropertyDescriptor trap). Basically,
>> getPropertyDescriptor may say that a property is configurable while
>> getPrototypeOf+getOwnPropertyDescriptor(on a native object which allows
>> non-configurable property) may say that the property is not-configurable.
>> They would both talk about the same property and be inconsistent.
>  Yes, this is a thorny issue. We could drop the getPropertyDescriptor
> operation & trap. What we lose by that is that proxies would be unable to
> fully emulate inherited properties. That is: while a proxy's get/set traps
> may still emulate "foo" as an inherited property (i.e. proxy.foo returns a
> value, but Object.getOwnPropertyDescriptor(proxy,'foo') returns undefined),
> the illusion would be broken once the proxy's inheritance chain is inspected
> (i.e. code may find out that there's actually no "foo" property on the
> proxy's prototype chain). Actually, one could argue that even without
> getPropertyDescriptor proxies already cannot emulate prototype inheritance,
> since they can't virtualize Object.getPrototypeOf.
> For the getPropertyDescriptor trap, if the returned descriptor has
> "configurable:false", the engine could climb the prototype chain to check
> that "configurable:false" is actually legitimate (only configurability). May
> be costly?

Ugh :-/
I'm not keen on mandating such prototype-climbing checks.

If given the choice, I would prefer taking away the complexity introduced by
|getPropertyDescriptor| by removing the proposed built-in + the trap, rather
than mandating more consistency checks.

> To summurize fixed propeties property-specific trap behaviors, one could
> say that:
> - defineProperty trap is called (and its return value is meaningful as
> explained on the current strawman)
> (if approved) - getOwnPropertyDescriptor trap is called (and its return
> value is meaningful the same way)
> - delete rejects
> - All other property-specific traps have the default derived trap behavior
> (all the remaining property-specific traps are derived).
> Does that sounds right?

Yes, sounds right to me.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110619/a5547962/attachment.html>

More information about the es-discuss mailing list