[Harmony Proxies] Adding a defineProperties derived trap

David Bruant bruant at enseirb-matmeca.fr
Tue Mar 15 04:35:09 PDT 2011

Le 15/03/2011 04:24, David Herman a écrit :
> [Oh sorry, I'm behind on the iteration-order mega-thread. I'll have to
> catch up.]
Summury of how the iteration thread may affect this proposal:

If the iteration-order thread ends up to the conclusion that for objects
({}-like objects, not arrays or any other form of object) properties
(any properties indifferently of being numeric or not) are ordered by
order of creation/addition/deletion in ECMAScript and enumeration in
for-in/keys reflects that order, then my proposal is pointless (actually
not, see after) since the thing I want to implement (OrderedObjects)
with is already ECMAScript objects.

> On Mar 14, 2011, at 1:16 PM, David Herman wrote:
>> Hi David,
>> We have a strawman for making the enumeration order well-specified:
>>     http://wiki.ecmascript.org/doku.php?id=strawman:enumeration
If the conclusion of the iteration-order thread is any different like
this strawman (index-like properties first even for {}-like objects) or
like keeping the order implementation-dependent, then my proposal of
adding a defineProperties trap provides the implementor of an
OrderedObject library (based on proxies) to throw on the
defineProperties trap to basically say "I cannot garranty my invariant,
because according to the ES spec, Object.defineProperties doesn't hold
the property I am supposed to hold myself (keeping track of order)".

>> Would that not be sufficient for the defineProperties case? I'd
>> prefer that to adding another trap.
In order to implement OrderedObject with proxies and keep the invariant
I want them too, the enumeration strawman is actually more a pro of a
new trap than a con.

Regardless of what is being specified, implementations may implement the
Proxy object but keep implementation-defined enumeration order. The
defineProperties trap would be a protection against these cases.

I am not 100% of a fan of adding traps easily either, however, first, I
am proposing to add a derived trap (which is far less restrictive than a
fundamental trap). Then, I think that this Object.defineProperties has a
dependance on something the user has no control whatsoever on
(enumeration order). I think that the new trap I am proposing is the
best protective mecanism against this dependency.

Now that I think about it, in my particular case, the defineProperties
doesn't have to throw. It could be implemented as:
defineProperties: function(pdmap){
    if(pdmap instanceof OrderedObject){
        /* retrieve pdmap property names in order and add then with the
same order through this.defineProperty */
        throw OrderedObjectError("I cannot guaranty enumeration order if
I perform this operation");


>> Dave
>> On Mar 12, 2011, at 1:15 PM, David Bruant wrote:
>>> Hi,
>>> The thread entitled "iteration order for Object" made me realize
>>> that there is no defineProperties trap.
>>> Let's imagine I'd like to implement an object which would keep track
>>> of order in which own properties have been added/deleted to it. With
>>> the defineProperty and delete traps I can already track order of
>>> addition/deletion and reflect it on the enumerate/keys trap when
>>> required.
>>> However, as of ES5, if I do:
>>> Object.defineProperties(proxy, props)
>>> then the defineProperty trap is called for each own property of
>>> props with an order chosen by the ES implementation (it's the same
>>> order than the one used in for..in which is
>>> implementation-dependent). Consequently, I cannot guarantee the
>>> object user that these keys will be enumerated with the order s/he
>>> provided them in props.
>>> A defineProperties trap could allow me to throw an error saying
>>> roughly "I can't garantee my invariant with such a call, please tell
>>> me explicitely the order you want for your properties by using
>>> several Object.defineProperty".
>>> It would obviously be a derived trap. The implementation is quite
>>> straightforward (based on ES5 Object.defineProperties algorithm
>>> with one subtility: when retrieving all own enumerable
>>> property names of the props object, if props is itself a proxy, then
>>> the keys trap of this proxy would be called.
>>> David
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
>>> https://mail.mozilla.org/listinfo/es-discuss
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org <mailto: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/20110315/e9548490/attachment-0001.html>

More information about the es-discuss mailing list