On Tue, Apr 29, 2014 at 5:49 PM, Allen Wirfs-Brock <[email protected]>wrote:
> > On Apr 30, 2014, at 8:43 AM, Jason Orendorff <[email protected]> > wrote: > > > The [[Origin]] field of Property Descriptor Records is not yet > > implemented in Firefox. Eric Faust is looking at implementing it.[1] > > We noticed two interesting cases: > > > > 1. Suppose handler.getOwnPropertyDescriptor returns ({value: 0}). Then > > 9.5.5 Proxy.[[GetOwnProperty]] calls 6.2.4.6 > > CompletePropertyDescriptor, and all the fields of the Property > > Descriptor Record are populated. But the object itself is not > > populated. This means Object.getOwnPropertyDescriptor will return an > > object that is missing most of the fields the caller wants to know > > about. This seems strange. > > The idea is that a Proxy can define its own property descriptor formats > that it exposes to and accepts form user code. vis > Object.defineProperty/Object.getOwnPropertyDescriptors. This includes the > possibility of new property attributes and censoring built-in attributes. > > For example, you might define a Proxy that exposes something like a typed > array but which did not have any attributes on indexed properties. Such a > Proxy might decided to return only {value: 0} as the descriptor for such a > zero-valued property. > > > > > 2. The object returned by the handler can have getters. It can answer > > ToPropertyDescriptor's queries one way, and then say something else > > afterwards, making it look like language invariants have been broken. > > Mostly, such custom descriptors are only returned to user code. I don’t > believe (it’s been while since I looked at this part of the spec, but once > upon a time I traced all these logic paths) there are any paths within > actual specified operations where a property descriptor is accessed in this > manner and that descriptor is immediately used to define another property. > > There aren’t any internal invariant sensitivities that I could find. Once > such a non-standard descriptor is never directly used by any of the > ordinary object MOP operations > I'm surprised and alarmed by this, and it seems wrong. It is also not what I think I remember. What about, for example, the invariant that an object cannot both claim that a property is non-configurable but then later change its alleged configuration? The issue isn't just the internal perception by other internal procedures,but obviously also the observations by user code. What I think I remember is that a proxy can add other fields to a property descriptor object, but that it cannot change the behavior of any of the ES6-defined fields (the usual .value, .writable, .set, .get, .enumerable, .configurable), not even to censor them. Am I misunderstanding something? If not, this seems like a huge disconnect for which we need to stop the train. > > > > > > > Come to think of it, [[GetOwnProperty]] is a weird API. It computes > > two results: a set of Property Descriptor fields, and an [[Origin]] > > object. The ES language itself relies exclusively on the former. > > Scripts are only allowed to see the latter. That seems really weird to > > me. > > > > Yes, that is the design. The set of fields are for internal use of > specified operations. The [[Origin]] field is there so a handler can > produce a non-standard descriptor and pass it back to user code. It is > necessary, because [[GetOwnDescriptor]] returns an internal record, not an > object. > > > What is an example of a concrete use case for this [[Origin]] feature? > > Is it to avoid allocating a new object here? > > So a Proxy can define the property descriptors it produces and consumes. > For example, you might have a property descriptor like: {method: func, > referencesSuper: boolean} > > Allen > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
