Perhaps @@unscopable shouldn't be a Set...
andre.bargull at udo.edu
Wed Apr 30 14:53:34 PDT 2014
The changes from https://bugs.ecmascript.org/show_bug.cgi?id=1908 never
made it into the spec.
On 4/30/2014 11:41 PM, André Bargull wrote:
>> Where do you find the spec incomplete WRT @@unscopable. My recollection was that it was all resolved and fully specified and that I was relatively happy with the outcome.
> unscopables for the Object Environment Record is always the empty
> list. It's never populated.
>> On May 1, 2014, at 3:00 AM, Erik Arvidsson <erik.arvidsson at gmail.com <https://mail.mozilla.org/listinfo/es-discuss>> wrote:
>> >/ This was never resolved and the spec is incomplete here
>> />/ On Wed Sep 25 2013 at 6:17:32 PM, Allen Wirfs-Brock <allen at wirfs-brock.com <https://mail.mozilla.org/listinfo/es-discuss>> wrote:
>> />/ So here is another concern, about the scheme we agreed to last week.
>> />/ It needs to match a found own property against the possibility of an own @@unscopable property on the same object and that object may be somewhere up the inheritance chain of the actual with object. The means that [[HasProperty]]/[[Get]]/[[Set]] can not be used to do those resolve binding in an ObjectEnvironmentRecord because they don't tell us where the property was found. Instead, ObjectEnvironmentRecord needs to reimplement its own property lookup using [[GetOwnProperty]] and [[GetInheritanceOf]]. However, if the with object is a proxy that means we may be bypassing the actual inheritance mechanism implemented by the Proxy's 'has'/'get'/'set' traps and that could introduce observable semantics irregularities.
>> />/ Specifying the duplicated lookup is doable but a pain. That and the semantic issues WRT proxies makes me a lot less comfortable with the added complexity of supporting @@unscopable.
>> />/ Allen
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss