2012/11/1 David Bruant <[email protected]> > Currently, TrapGetOwnProperty returns an object, but when there is an > actual trap, it goes through: > * NormalizeAndCompletePropertyDescriptor(Object) -> Object (step 6) > * ToCompletePropertyDescriptor(Object) -> PropertyDescriptor (step 3 of > NormalizeAndCompletePropertyDescriptor) > * FromPropertyDescriptor(PropertyDescriptor) -> Object (step 4 of > NormalizeAndCompletePropertyDescriptor) > > We might as well get rid of the spec-only PropertyDescriptor, define an > equivalently pre-condition/invariant enforcing ES5 construct and > manipulate that both internally and in trap boundaries. >
I think the deal-breaker, as Allen pointed out, is that what you call an ESUsablePropDesc would still need to be mutable (if it wants to mimic current property-descriptors-as-objects-with-some-invariants). Plus, it doesn't get rid of the implicit conversions at proxy boundaries. In the case of defineProperty you'd still have to convert between a plain object passed in as 3rd arg, and an ESUsablePropDesc. In the case of getOwnPropertyDescriptor, to preserve current semantics, you must still copy the (mutable) ESUsablePropDesc to ensure that all calls to getOwnPropertyDescriptor return fresh, independent objects. Granted, having an ESUsablePropDesc would avoid conversions in the case of proxies forwarding the operation to their target. Thanks for drawing my attention to the auxiliary functions: it made me realize that Aux.3 NormalizePropertyDescriptor and Aux 4. NormalizeAndCompletePropertyDescriptor are only called in one place. I think that by in-lining their definitions we might get rid of some redundant conversions. That said, the "redundancy" you point out, i.e. the conversion from Object -> PropDesc immediately followed by PropDesc -> Object is not really redundant: it's needed to "normalize" the descriptor. Implementations can probably optimize so that they don't actually have to allocate an intermediate internal property descriptor, but immediately create an Object copy. > The way I see it now, ESUsablePropDesc would be a regular object with a > bunch of getter/setters to enforce property descriptor invariants. > Everything would remain compatible (unless people really cared that ES5 > descriptors have data properties). Unfortunately it's not a question of caring: currently, an ES5 meta-program can make the valid assumption that all "standard" attributes of a property descriptor object are data properties. Changing this assumption is not backwards-compatible. Cheers, Tom
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
