Object.defineProperties (seemingly) requires transactional behaviour

Oliver Hunt oliver at apple.com
Mon Sep 21 18:35:04 PDT 2009

To have a truly correct implementation of Object.defineProperties (as  
currently defined) an implementation would in effect have to implement  
transaction updates to Objects, as [[DefineOwnProperty]] is  
polymorphic and behaviour cannot be guaranteed.

As a simple example (excluding host objects even)

myArray = [1,2,3,4];
Object.defineProperties(myArray, {length: {value:2}, 2:{value:4}})

Even if an implementation were to implement two versions of  
[[DefineOwnProperty]] for every object (one that did the logic to  
determine whether a given call to [[DefineOwnProperty]] was correct,  
one that actually defined it -- and this behaviour should be  
specified, currently the definition of defineOwnProperties seems  
woefully inadequate), both the assignment to length and the assignment  
to property 2 are valid during preflight.  Once we call  
[[DefineOwnProperty]] with the intention of actually setting the  
values we set the length property, subsequently removing the property  
2, which in turn means that setting property 2 must fail.

This is nuts -- i am leaning towards the belief that defineProperty,  
defineProperties, seal, preventExtensions, et al. should only work  
when applied to pure objects, not any host object, nor any of the  
special builtins.  All other paths seems to lead to absurd and/or  
complex and unexpected behaviour.


More information about the es5-discuss mailing list