Re: Object.getOwnPropertyDescriptor can return just about anything
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.r...@gmail.com: On Thu, May 8, 2014 at 5:23 PM, Tom Van Cutsem tomvc...@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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Native base64 utility methods
Mathias Bynens wrote:
(but it requires `ArrayBuffer` / `Uint8Array`).
In ES6, so no problem proposing Text{En,De}coder for ES7.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Object.getOwnPropertyDescriptor can return just about anything
Le 09/05/2014 08:50, Tom Van Cutsem a écrit : 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). Just to try to assess the unlikelihood and understand the cases where a ES5 code expectations aren't met: The only case where ES6 and ES5 may diverge is for Object.getOwnPropertyDescriptor where a Proxy may return something that cannot be expected from any ES5 object. The after-trap completes the property descriptor (and when completing picks specifically only data or accessor property), so code that expects a complete property descriptor cannot be broken. However, a divergence may only occur if, for instance, the code loops over the property descriptor properties or expects exactly 4 properties. Is that correct or am I missing cases? David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Object.getOwnPropertyDescriptor can return just about anything
2014-05-09 9:57 GMT+02:00 David Bruant bruan...@gmail.com: Just to try to assess the unlikelihood and understand the cases where a ES5 code expectations aren't met: The only case where ES6 and ES5 may diverge is for Object.getOwnPropertyDescriptor where a Proxy may return something that cannot be expected from any ES5 object. The after-trap completes the property descriptor (and when completing picks specifically only data or accessor property), so code that expects a complete property descriptor cannot be broken. However, a divergence may only occur if, for instance, the code loops over the property descriptor properties or expects exactly 4 properties. Is that correct or am I missing cases? Another possibility would be that existing client code itself extends property descriptors with new attributes (since descriptors returned by gOPD are always extensible), and can then get confused when proxies pre-populate these descriptors with their own custom attributes. But again, this is highly unlikely. I think allowing proxies to accept/return custom attributes remains feasible. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Object.getOwnPropertyDescriptor can return just about anything
By the same token, it is feasible to postpone these custom attributes till ES7. My concern is that since the [[Origin]]-oriented proxy proposal that has been in the draft spec was a distracting dead end[1], we should be conservative in returning to the design that preserves the crucial invariants. The custom attributes seem safe enough, but we have too much on our plate and it is safer yet to postpone them. Nothing else depends on the presence of these custom attributes being in ES6. [1] My apologies once again for not paying enough attention to catch this early. On Fri, May 9, 2014 at 5:23 AM, Tom Van Cutsem tomvc...@gmail.com wrote: 2014-05-09 9:57 GMT+02:00 David Bruant bruan...@gmail.com: Just to try to assess the unlikelihood and understand the cases where a ES5 code expectations aren't met: The only case where ES6 and ES5 may diverge is for Object.getOwnPropertyDescriptor where a Proxy may return something that cannot be expected from any ES5 object. The after-trap completes the property descriptor (and when completing picks specifically only data or accessor property), so code that expects a complete property descriptor cannot be broken. However, a divergence may only occur if, for instance, the code loops over the property descriptor properties or expects exactly 4 properties. Is that correct or am I missing cases? Another possibility would be that existing client code itself extends property descriptors with new attributes (since descriptors returned by gOPD are always extensible), and can then get confused when proxies pre-populate these descriptors with their own custom attributes. But again, this is highly unlikely. I think allowing proxies to accept/return custom attributes remains feasible. -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ToPropertyDescriptor, [[HasProperty]], [[HasOwnProperty]]
On May 8, 2014, at 9:08 PM, Mathias Bynens wrote: On Fri, May 9, 2014 at 1:44 AM, John-David Dalton john.david.dal...@gmail.com wrote: Should I create a spec bug for tracking this? Please do. Even better, submit a strawman proposal allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ToPropertyDescriptor, [[HasProperty]], [[HasOwnProperty]]
Rock, will do. Thanks! - JDD ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ToPropertyDescriptor, [[HasProperty]], [[HasOwnProperty]]
just wrote this down ... it takes an eye blink to agree with and adopt even in ES6, IMHO https://gist.github.com/WebReflection/48aecb771e61e8a3e168 On Fri, May 9, 2014 at 11:08 AM, John-David Dalton john.david.dal...@gmail.com wrote: Rock, will do. Thanks! - JDD ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ToPropertyDescriptor, [[HasProperty]], [[HasOwnProperty]]
also, on top of this ... I'd like to add the fact that es5-sham, the drop in everyone thinks is cool to use to support old browsers not compatible with ES5, is entirely based on own properties since ever: https://github.com/es-shims/es5-shim/blob/master/es5-sham.js#L310 the owns definition in that scope: https://github.com/es-shims/es5-shim/blob/master/es5-sham.js#L28 I've never filed a bug against it, because as it is it has been just safer for the old Web Best Regards P.S. we are 1 year later on fixing this :-( On Fri, May 9, 2014 at 6:53 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: just wrote this down ... it takes an eye blink to agree with and adopt even in ES6, IMHO https://gist.github.com/WebReflection/48aecb771e61e8a3e168 On Fri, May 9, 2014 at 11:08 AM, John-David Dalton john.david.dal...@gmail.com wrote: Rock, will do. Thanks! - JDD ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
