[Harmony Proxies] Proposal: Property fixing

Tom Van Cutsem tomvc.be at gmail.com
Wed Jun 15 04:34:28 PDT 2011

2011/6/14 Allen Wirfs-Brock <allen at wirfs-brock.com>

> Doesn't this new proposal still preclude using proxies to create an exact
> emulation of the built-in Array object type.  The "length" property of
> arrays is specified to be non-configurable yet special behavior must occur
> each time the value of length is changed.  The proposal would allow "length"
> to be "fixed"  as an accessor property whose set behavior did the necessary
> processing.  However, that is also a violation of the Array specification as
> it requires that "length" exhibit the attributes of a data property.

It is true that this strawman would not enable a faithful emulation of the
Array "length" property at the meta-level (i.e. when looking at an object as
a set of property descriptors). I can't yet judge how much of an issue this
is: given the novelty of the property descriptor API, I don't know how much
code such an imperfect Array proxy would break. At least at the "base-level"
(i.e. regular application code), "length" would be updated as expected, and
remains accessible as "arrayproxy.length".

(As an aside: re. the emulation of arrays, having a configurable [[Class]]
such that |Object.prototype.toString.call(arrayproxy)| can return "[object
Array]" seems like a more important imperfection to fix)

> I emphasize Array when I look at this simply because it is a fairly simple
> example of the sort of thing that a host object might currently do and the
> most important use case of proxies for me is the replacement/emulation of
> host objects.  I really don't know where this idea that non-configurable
> implies no special semantics comes from.  That isn't the case in the ES5
> specification  (10.6,,, for such
> properties.

I'm not sure what you mean by special semantics. If you mean strong
guarantees/invariants, then one example would be that a non-writable,
non-configurable data property is guaranteed to have a stable value. The
proposed strawman allows proxies to define such properties, at the expense
of giving up interception of access to such a property.


> Allen
> On Jun 14, 2011, at 1:57 AM, Tom Van Cutsem wrote:
> Hi,
> To address the outstanding issue of how proxies should deal with
> non-configurable properties, I picked up on Sean's earlier proposal, adapted
> it and turned it into a strawman: <
> http://wiki.ecmascript.org/doku.php?id=strawman:fixed_properties>.
> My adaptation is more permissive than the original proposal in that it
> still allows proxies to intercept access to non-configurable properties if
> they are willing to expose them as accessor rather than data properties.
> This proposal would allow proxies to cover more use cases (because they can
> now emulate non-configurable properties), at the expense of additional
> complexity within proxy objects.
> As always, discussion and feedback are appreciated.
> Cheers,
> Tom
> 2011/5/4 Sean Eagan <seaneagan1 at gmail.com>
>> What:
>> Honor attempts to make individual proxy properties non-configurable.
>> Why:
>> For consistency since attempts to make *all* of a proxy's properties
>> non-configurable are honored via the "fix" trap.
>> Example:
>> var x = Proxy.create({
>>  defineProperty: function() {},
>>  getPropertyDescriptor: function() {
>>    return {
>>      value: "whatever I want",
>>      writable: true,
>>      configurable: true,
>>      enumerable: false
>>    };
>>  }
>> });
>> Object.defineProperty(x, "foo", {value: "bar", configurable: false,
>> writable: false, enumerable: true};
>> /* ... */
>> // logs "whatever I want", not "bar"
>> console.log(x.foo);
>> // non-writable, but doesn't throw
>> object.foo = "baz";
>> // non-configurable, but doesn't throw
>> Object.defineProperty(x, "foo", {configurable: true});
>> How:
>> Assume a "defineProperty" trap invocation due to
>> |Object.defineProperty(proxy, name, pd)| where |!pd.configurable|.  If
>> return value is...
>>  true - Henceforth bypass |proxy|'s handler for any traps with a
>> property name parameter when the property name would be |name|
>>  false - throw TypeError similarly to "fix" trap
>> Update the "fix" trap semantics such that when its return value is not
>> undefined but rather a property descriptor map, behavior is similar to
>> |Object.defineProperties| in that improperly redefining any properties
>> will cause a TypeError to be thrown.
>> Notes:
>> Can check |Object.getOwnPropertyDescriptor(proxy, name).configurable|
>> to determine if a given proxy property is fixed since it will always
>> be false in this case.
>> Thanks,
>> Sean Eagan
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110615/bd5e5fbb/attachment.html>

More information about the es-discuss mailing list