[Harmony Proxies] Proposal: Property fixing

Sean Eagan seaneagan1 at gmail.com
Tue Jun 14 12:56:55 PDT 2011


Hi Allen,

I believe the best way to enable emulation of each builtin type would
be to orthogonalize the proxy semantics, such that proxies are no
longer a separate language type, but rather an internal capability
accessible to all object types.  This for example would allow for
creation of array proxies whose internal [[DefineOwnProperty]]
internal property is 15.4.5.1 just as with regular arrays, where
8.12.9 is updated with "defineProperty" trapping semantics, so the
"defineProperty" trap would be invoked for both the "length" property
and the array index property on calls to the array proxy's
[[DefineOwnProperty]] internal method.  It might additionally be
useful to allow proxies to override the entirety of 15.4.5.1, in which
case there could be a "defineArrayProperty" trap for this purpose.
The same thing idea would be used to allow proxies to emulate 10.6,
15.3.5.4, 15.5.5.2.  As in
https://mail.mozilla.org/pipermail/es-discuss/2011-May/014838.html
these default behaviors would just be the existing prose rather than
duplicate ES-defined default trap implementations.

A possible API for such an orthogonalized proxy semantics might be
"object descriptors" an object level equivalent to property
descriptors, where one of the object level attributes is "handler" (
[[Handler]] ).  I am working on a formal proposal which includes all
of these concepts, hope to get it out soon.

Would this alleviate some of your concerns with the "fixed properties" proposal?

On Tue, Jun 14, 2011 at 11:56 AM, Allen Wirfs-Brock
<allen at wirfs-brock.com> wrote:
> 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.
> 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,15.3.5.4,15.4.5.1+15.4.5.2, 15.5.5.2) for such
> properties.
> 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
>
>



-- 
Sean Eagan


More information about the es-discuss mailing list