ToPropertyDescriptor and [[DefineOwnProperty]], regarding Object.defineProperty
jwalden+es at MIT.EDU
Mon Jun 1 12:40:06 PDT 2009
I'm working on implementing Object.defineProperty now, so I'm spending some quality time with ToPropertyDescriptor and [[DefineOwnProperty]].
I find the arcane structure of property descriptors, which have a fixed set of named fields but which might end up omitting any of those fields, very complicated. Recall that the properties of a descriptor are [[Enumerable]], [[Configurable]], [[Writable]], [[Value]], [[Get]], and [[Set]]. That's 2**6 possible ways that fields may or may not be present. Looking simply at ToPropertyDescriptor, we can eliminate some combinations of fields as possible through the second-to-last step, (9 * 2**2) of them at a quick glance (math may be wrong). That still leaves 28 different possible combinations of fields that may be present in a valid descriptor. Testing that many different combinations isn't quite simple -- and we're only in ToPropertyDescriptor yet.
Now consider the complexity multiplier of [[DefineOwnProperty]], specified on the numbered page 39 (PDF page 53) of the candidate spec. Take a look at that method, and try to formulate an accurate estimate of the number of different ways this method splits based on which fields are or are not present in the input property descriptor.
Could you guesstimate such a number? I'm not sure I could without dropping a lot of time to do so. Oh, and let's not even forget that that's only for non-array objects -- they have their own [[DefineOwnProperty]] that further increases complexity. (Of course, even beyond the complexity omittable fields introduces, let's not forget complexity due to the field values!)
I don't see the point in making fields of property descriptors omittable. We can't avoid complexity based on the field values themselves, but having fields be omittable seems like mostly needless complexity to me. Specifying default values for property descriptors which might otherwise have omitted fields (in ToPropertyDescriptor and [[GetOwnProperty]]) appears not to be especially complicated. A property descriptor, then, would be treated as an accessor descriptor if [[Get]] or [[Set]] were not undefined, and otherwise it would be treated as a data descriptor. This might, in rare circumstances, require the user to specify more values in the object to be converted to a property descriptor as provided to Object.definePropert(y|ies), but I don't see that as a particular problem, and I expect it will be extremely rare for a property to be defined more than once with these methods.
Making property descriptors have a fixed number of fields eliminates a fair amount of complexity at not much expense, and I don't see a reason why the spec shouldn't say this.
0. Throughout this email any reference to a "property descriptor" refers to the specification type, not to the reification of one as exposed by Object.getOwnPropertyDescriptor or to the object taken as an argument by ToPropertyDescriptor.
More information about the es-discuss