Rick,

It's true that allowing user-invented custom attributes will not break any
important existing invariants (except perhaps that all existing descriptors
can be assumed not to have any own properties besides the standard
attributes. Existing code may depend on that, although it feels highly
unlikely).

Cheers,
Tom



2014-05-09 0:11 GMT+02:00 Rick Waldron <waldron.rick at gmail.com>:

>
>
>
> On Thu, May 8, 2014 at 5:23 PM, Tom Van Cutsem <tomvc.be at gmail.com> wrote:
>
>> Allen, Mark and I discussed the [[Origin]] issue and came to the
>> following consensus:
>>
>> We remove [[Origin]] and revert to the originally specified behavior (<
>> http://wiki.ecmascript.org/doku.php?id=harmony:proxies_spec>) where the
>> descriptor returned by the proxy is coerced into a fresh, normalized,
>> completed, ordinary descriptor object.
>>
>> This ensures complete backward-compatibility with the ES5 behavior (i.e.
>> Object.getOwnPropertyDescriptor will always return a fresh, complete data
>> or accessor descriptor), and doesn't allow a proxy to play tricks with
>> descriptor objects.
>>
>> Allen's remaining concern is that this disallows proxies (or new exotic
>> objects) from inventing new types of descriptors, next to data and accessor
>> descriptors. Due to backwards-compat. constraints, we're basically stuck
>> with these two types of property descriptors forever.
>>
>> The originally specified Proxy behavior also included copying any
>> non-standard attributes provided by the proxy onto the fresh descriptor
>> object. However, if we're serious about keeping
>> Object.getOwnPropertyDescriptor backwards-compatible with existing ES5
>> code, we may be better off by not augmenting descriptor objects with
>> non-standard attributes, even if this is unlikely to break existing code.
>> As Jason mentioned, if proxies want to introduce new per-property
>> attributes, they can provide other means of getting at that meta-data
>> rather than abusing the standard reflection API.
>>
>> So, the current proposal is to spec [[GetOwnProperty]] for Proxies such
>> that the descriptor returned by the trap is coerced into a fresh,
>> normalized, complete descriptor object, without copying custom attributes.
>>
>> Relevant bug seems to already have been filed by Andre: <
>> https://bugs.ecmascript.org/show_bug.cgi?id=2382>
>>
>
> Forgive me if this has already been discussed elsewhere, but the "Notes"
> section of [[GetOwnProperty]](P) lists several invariants that are similar
> in nature to the following (which I've just made up):
>
> - A property cannot be reported as configurable, if it does not exists as
> an own property of the target object or if it exists as a non-configurable
> own property of the target object.
>
> - A property cannot be reported as writable, if it does not exists as an
> own property of the target object or if it exists as a non-writable own
> property of the target object.
>
> - A property cannot be reported as enumerable, if it does not exists as an
> own property of the target object or if it exists as a non-enumerable own
> property of the target object.
>
>
> Then descriptors would allow user-invented descriptor properties, while
> still upholding the target's integrity.
>
>
> Rick
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140509/4e028d1d/attachment.html>

It's true that allowing user-invented custom attributes will not break any
important existing invariants (except perhaps that all existing descriptors
can be assumed not to have any own properties besides the standard
attributes. Existing code may depend on that, although it feels highly
unlikely).