On Jan 5, 2013, at 12:24 AM, Tom Van Cutsem wrote:
> 2013/1/4 Allen Wirfs-Brock
>
> ...
>
> You're concerned about the nature of the descriptor object returned from the
> getOwnProertyDescriptor trap. In particular, you want to have something
> stable enough that you can reason about it and
2013/1/4 Allen Wirfs-Brock
>
> On Jan 4, 2013, at 12:05 AM, Tom Van Cutsem wrote:
>
> From your point of view, it's only natural that proxies would be an ES6
> programmer's tool to define and experiment with entirely new types of
> properties.
>
> From my point of view, it's problematic (as in: n
On Jan 4, 2013, at 12:05 AM, Tom Van Cutsem wrote:
> From your point of view, it's only natural that proxies would be an ES6
> programmer's tool to define and experiment with entirely new types of
> properties.
>
> From my point of view, it's problematic (as in: not backwards-compatible)
> th
2013/1/3 Allen Wirfs-Brock
>
> On Jan 3, 2013, at 12:18 AM, Tom Van Cutsem wrote:
>
> I think it's perfectly obvious what it means for an exotic property to be
> complete: that it is at least a complete data or accessor property (i.e. it
> either has {value,writable,enumerable,configurable}, or i
On Jan 3, 2013, at 12:18 AM, Tom Van Cutsem wrote:
> 2013/1/3 Allen Wirfs-Brock
>
> On Dec 31, 2012, at 3:37 AM, Tom Van Cutsem wrote:
>
>> [...]
>
>>
>> However, this semantics also implies that:
>> 1) pd2 is not a completed property descriptor, lacking a writable/enumerable
>> attribute.
2013/1/3 Allen Wirfs-Brock
>
> On Dec 31, 2012, at 3:37 AM, Tom Van Cutsem wrote:
>
> [...]
>
>
> However, this semantics also implies that:
> 1) pd2 is not a completed property descriptor, lacking a
> writable/enumerable attribute. Only the internal property descriptor was
> fully completed, not
On Dec 31, 2012, at 3:37 AM, Tom Van Cutsem wrote:
> 2012/12/30 Allen Wirfs-Brock
>
> On Dec 29, 2012, at 2:37 PM, Tom Van Cutsem wrote:
> > * I'm a bit uncomfortable with the removal of property descriptor
> normalization in the getOwnPropertyDescriptor/defineProperty traps.
> Especially fo
On Dec 31, 2012, at 7:28 AM, Brandon Benvie wrote:
>
> On Monday, December 31, 2012, Tom Van Cutsem wrote:
> That said, I think this issue is orthogonal to our choice of whether or not
> to expose "setPrototypeOf" as part of the MOP. Even if we do expose it, any
> sandbox that wants to take aw
On Monday, December 31, 2012, Tom Van Cutsem wrote:
>
> That said, I think this issue is orthogonal to our choice of whether or
> not to expose "setPrototypeOf" as part of the MOP. Even if we do expose
> it, any sandbox that wants to take away the ability the set the prototype
> can simply poison R
2012/12/30 Allen Wirfs-Brock
>
> On Dec 29, 2012, at 2:37 PM, Tom Van Cutsem wrote:
> > * I'm a bit uncomfortable with the removal of property descriptor
> normalization in the getOwnPropertyDescriptor/defineProperty traps.
> Especially for getOwnPropertyDescriptor I think it's a breaking change
2012/12/30 Allen Wirfs-Brock
>
> On Dec 29, 2012, at 2:37 PM, Tom Van Cutsem wrote:
> > * [[SetInheritance]]/Reflect.setPrototypeOf: I'm not sure this was
> agreed upon. Especially since __proto__ is currently specified as a data
> property. This means there is no setter that separately reifies
Ah yes, I take it back. For some reason I had the mistaken notion that the
[[Origin]] was somehow planned to propagate/persist further, rather than
just being a way to support lossless maybe-forward (I believe this is the
purpose?). I must have crossed signals on something else, since I recall
read
On Dec 30, 2012, at 2:57 PM, Brandon Benvie wrote:
>
> Wouldn't it be possible to make a copy of the provided descriptor object and
> otherwise work the same as it is currently specified? This retains the
> ability to set and get custom descriptor attributes without making the stored
> record
Wouldn't it be possible to make a copy of the provided descriptor object
and otherwise work the same as it is currently specified? This retains the
ability to set and get custom descriptor attributes without making the
stored record mutable, which seems like the primary concern.
On Sun, Dec 30, 20
(err, response not respinse...)
My response to the general comments are below. I'll respond to comments for
specific sections in separate messages.
On Dec 29, 2012, at 2:37 PM, Tom Van Cutsem wrote:
> Hi,
>
> I did a thorough revision of Allen's Rev12 and Rev13 drafts which incorporate
> (
15 matches
Mail list logo
