On Tue, Apr 29, 2014 at 5:49 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:

>
> On Apr 30, 2014, at 8:43 AM, Jason Orendorff <jason.orendorff at gmail.com>
> 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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140429/75cb531a/attachment-0001.html>

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.