Re: Object.freezing proxies should freeze or throw?

[Mark S. Miller]

On Mon, Aug 8, 2016 at 1:35 PM, Tom Van Cutsem  wrote:

> Claude's additional example is indeed evidence that Object.freeze is not
> to blame, but rather that the invariant checks of
> [[GetOwnPropertyDescriptor]] and [[DefineOwnProperty]] are too weak. The
> culprit is, as far as I can tell, that we re-used the state transitions
> allowed by DefineOwnProperty, which allows the transition from
> non-configurable,writable (-c+w) to non-configurable,non-writable (-c-w)
> and which is unwanted here, as Claude rightfully concludes *[to better
> understand the state transitions involved, see MarkM's lucid state
> transition chart of property attributes
>  >. I wish
> this diagram were in the spec btw, once you know how to read it, it is
> significantly easier to understand than the DefineOwnProperty algorithm
> itself]*
>

I would like to see it in the spec too.


>
> I like the simplicity of Claude's suggestion, but I think that check is
> too tight. Technically if the descriptors are both -c+w data descriptors,
> their value attributes need not be identical to honor the spec invariants.
> Instead I would propose to tackle the problem head-on and explicitly
> disallow a proxy from reporting a -c-w property if the corresponding target
> property is -c+w. We already have a similar check in place in precisely
> those two algorithms to test if the configurable attribute matches. It is
> just a matter of tightening that check to also verify the writable
> attribute.
>
> This would entail the following changes to the ES2015 spec (new or
> modified text in bold):
>
>
> 9.5.5 [[GetOwnProperty]] (P)
>   ...
>   22. If resultDesc.[[Configurable]] is false, then
> a. If targetDesc is undefined or targetDesc.[[Configurable]] is true,
> then
>   i. Throw a TypeError exception.
> *b. If resultDesc.[[Writable]] is false and targetDesc.[[Writable]] is
> true, then*
> *  i. Throw a TypeError exception.*
>
> NOTE [[GetOwnProperty]] for proxy objects enforces the following
> invariants:
>
>   ...
> *  * A property cannot be reported as non-configurable, non-writable if it
> exists as a non-configurable, writable own property on the target object.*
>
>
> 9.5.6 [[DefineOwnProperty]] (P, Desc)
>   ...
>   20. Else targetDesc is not undefined,
> a.  If IsCompatiblePropertyDescriptor(extensibleTarget, Desc ,
> targetDesc) is false, throw a TypeError exception.
> *b. If settingConfigFalse is true*
> *  i. If targetDesc.[[Configurable]] is true, throw a TypeError
> exception.*
> *  ii. If Desc.[[Writable]] is false and targetDesc.[[Writable]] is
> true, throw a TypeError exception.*
>
> NOTE [[DefineOwnProperty]] for proxy objects enforces the following
> invariants:
>
>   ...
> *  * A property cannot be successfully set to non-configurable,
> non-writable if the corresponding own property of the target object is
> non-configurable, writable.*
>
> WDYT?
>
> Regards,
> Tom
>
> 2016-08-08 15:37 GMT+02:00 Claude Pache :
>
>>
>> > Le 8 août 2016 à 11:02, Claude Pache  a écrit :
>> >
>> > Here is another test case, with [[GetOwnPropertyDescriptor]]:
>> >
>> > ```js
>> > var target = Object.seal({x: 2});
>> > var proxy = new Proxy(target, {
>> >getOwnPropertyDescriptor(o, p) {
>> >var d = Reflect.getOwnPropertyDescriptor(o, p)
>> >if (d && 'writable' in d)
>> >d.writable = false
>> >return d
>> >}
>> > });
>> >
>> > Object.getOwnPropertyDescriptor(proxy, 'x'); // { value: 2, writable:
>> false, configurable: false }
>> >
>> > Object.defineProperty(proxy, 'x', { value: 3 })
>> >
>> > Object.getOwnPropertyDescriptor(proxy, 'x'); // { value: 3, writable:
>> false, configurable: false }
>> > ```
>> >
>> > IMHO, the most robust fix is the following: Both the
>> [[DefineOwnProperty]] and the [[GetOwnPropertyDescriptor]] contain the
>> following check:
>> >
>> > * If IsCompatiblePropertyDescriptor(extensibleTarget, resultDesc,
>> targetDesc) is false, throw a TypeError exception.
>> >
>> > I think there should be also the following check (except when
>> targetDesc is undefined, in which case another appropriate check is used):
>> >
>> > * If IsCompatiblePropertyDescriptor(extensibleTarget, targetDesc,
>> resultDesc) is false, throw a TypeError exception.
>> >
>> > That would replace the weaker adhoc check about the [[Configurable]]
>> attribute (search for settingConfigFalse) in those algorithms.
>> >
>> > (Alternatively, in order to avoid double checks, define an
>> AreBothWaysCompatiblePropertyDescriptors(extensibleTarget, desc1, desc2)
>> abstract operation.)
>> >
>> > —Claude
>> >
>>
>> Looking closer, it seems that using IsCompatiblePropertyDescriptor is in
>> fact an overkill, because we probably don’t want the special case of
>> conditionally mutable [[Writable]] attribute 

Re: Object.freezing proxies should freeze or throw?

[Tom Van Cutsem]

I just realized: since the tightened test is reading Desc.[[Writable]] but
Desc can by any descriptor, we probably need to first check whether Desc is
a DataDescriptor and disregard the writability test otherwise.

2016-08-08 22:35 GMT+02:00 Tom Van Cutsem :

> Claude's additional example is indeed evidence that Object.freeze is not
> to blame, but rather that the invariant checks of
> [[GetOwnPropertyDescriptor]] and [[DefineOwnProperty]] are too weak. The
> culprit is, as far as I can tell, that we re-used the state transitions
> allowed by DefineOwnProperty, which allows the transition from
> non-configurable,writable (-c+w) to non-configurable,non-writable (-c-w)
> and which is unwanted here, as Claude rightfully concludes *[to better
> understand the state transitions involved, see MarkM's lucid state
> transition chart of property attributes
>  >. I wish
> this diagram were in the spec btw, once you know how to read it, it is
> significantly easier to understand than the DefineOwnProperty algorithm
> itself]*
>
> I like the simplicity of Claude's suggestion, but I think that check is
> too tight. Technically if the descriptors are both -c+w data descriptors,
> their value attributes need not be identical to honor the spec invariants.
> Instead I would propose to tackle the problem head-on and explicitly
> disallow a proxy from reporting a -c-w property if the corresponding target
> property is -c+w. We already have a similar check in place in precisely
> those two algorithms to test if the configurable attribute matches. It is
> just a matter of tightening that check to also verify the writable
> attribute.
>
> This would entail the following changes to the ES2015 spec (new or
> modified text in bold):
>
>
> 9.5.5 [[GetOwnProperty]] (P)
>   ...
>   22. If resultDesc.[[Configurable]] is false, then
> a. If targetDesc is undefined or targetDesc.[[Configurable]] is true,
> then
>   i. Throw a TypeError exception.
> *b. If resultDesc.[[Writable]] is false and targetDesc.[[Writable]] is
> true, then*
> *  i. Throw a TypeError exception.*
>
> NOTE [[GetOwnProperty]] for proxy objects enforces the following
> invariants:
>
>   ...
> *  * A property cannot be reported as non-configurable, non-writable if it
> exists as a non-configurable, writable own property on the target object.*
>
>
> 9.5.6 [[DefineOwnProperty]] (P, Desc)
>   ...
>   20. Else targetDesc is not undefined,
> a.  If IsCompatiblePropertyDescriptor(extensibleTarget, Desc ,
> targetDesc) is false, throw a TypeError exception.
> *b. If settingConfigFalse is true*
> *  i. If targetDesc.[[Configurable]] is true, throw a TypeError
> exception.*
> *  ii. If Desc.[[Writable]] is false and targetDesc.[[Writable]] is
> true, throw a TypeError exception.*
>
> NOTE [[DefineOwnProperty]] for proxy objects enforces the following
> invariants:
>
>   ...
> *  * A property cannot be successfully set to non-configurable,
> non-writable if the corresponding own property of the target object is
> non-configurable, writable.*
>
> WDYT?
>
> Regards,
> Tom
>
> 2016-08-08 15:37 GMT+02:00 Claude Pache :
>
>>
>> > Le 8 août 2016 à 11:02, Claude Pache  a écrit :
>> >
>> > Here is another test case, with [[GetOwnPropertyDescriptor]]:
>> >
>> > ```js
>> > var target = Object.seal({x: 2});
>> > var proxy = new Proxy(target, {
>> >getOwnPropertyDescriptor(o, p) {
>> >var d = Reflect.getOwnPropertyDescriptor(o, p)
>> >if (d && 'writable' in d)
>> >d.writable = false
>> >return d
>> >}
>> > });
>> >
>> > Object.getOwnPropertyDescriptor(proxy, 'x'); // { value: 2, writable:
>> false, configurable: false }
>> >
>> > Object.defineProperty(proxy, 'x', { value: 3 })
>> >
>> > Object.getOwnPropertyDescriptor(proxy, 'x'); // { value: 3, writable:
>> false, configurable: false }
>> > ```
>> >
>> > IMHO, the most robust fix is the following: Both the
>> [[DefineOwnProperty]] and the [[GetOwnPropertyDescriptor]] contain the
>> following check:
>> >
>> > * If IsCompatiblePropertyDescriptor(extensibleTarget, resultDesc,
>> targetDesc) is false, throw a TypeError exception.
>> >
>> > I think there should be also the following check (except when
>> targetDesc is undefined, in which case another appropriate check is used):
>> >
>> > * If IsCompatiblePropertyDescriptor(extensibleTarget, targetDesc,
>> resultDesc) is false, throw a TypeError exception.
>> >
>> > That would replace the weaker adhoc check about the [[Configurable]]
>> attribute (search for settingConfigFalse) in those algorithms.
>> >
>> > (Alternatively, in order to avoid double checks, define an
>> AreBothWaysCompatiblePropertyDescriptors(extensibleTarget, desc1, desc2)
>> abstract operation.)
>> >
>> > —Claude
>> >
>>
>> Looking closer, it seems that using 

Re: Object.freezing proxies should freeze or throw?

[Tom Van Cutsem]

Claude's additional example is indeed evidence that Object.freeze is not to
blame, but rather that the invariant checks of [[GetOwnPropertyDescriptor]]
and [[DefineOwnProperty]] are too weak. The culprit is, as far as I can
tell, that we re-used the state transitions allowed by DefineOwnProperty,
which allows the transition from non-configurable,writable (-c+w) to
non-configurable,non-writable (-c-w) and which is unwanted here, as Claude
rightfully concludes *[to better understand the state transitions involved,
see MarkM's lucid state transition chart of property attributes
>. I wish
this diagram were in the spec btw, once you know how to read it, it is
significantly easier to understand than the DefineOwnProperty algorithm
itself]*

I like the simplicity of Claude's suggestion, but I think that check is too
tight. Technically if the descriptors are both -c+w data descriptors, their
value attributes need not be identical to honor the spec invariants.
Instead I would propose to tackle the problem head-on and explicitly
disallow a proxy from reporting a -c-w property if the corresponding target
property is -c+w. We already have a similar check in place in precisely
those two algorithms to test if the configurable attribute matches. It is
just a matter of tightening that check to also verify the writable
attribute.

This would entail the following changes to the ES2015 spec (new or modified
text in bold):


9.5.5 [[GetOwnProperty]] (P)
  ...
  22. If resultDesc.[[Configurable]] is false, then
a. If targetDesc is undefined or targetDesc.[[Configurable]] is true,
then
  i. Throw a TypeError exception.
*b. If resultDesc.[[Writable]] is false and targetDesc.[[Writable]] is
true, then*
*  i. Throw a TypeError exception.*

NOTE [[GetOwnProperty]] for proxy objects enforces the following invariants:

  ...
*  * A property cannot be reported as non-configurable, non-writable if it
exists as a non-configurable, writable own property on the target object.*


9.5.6 [[DefineOwnProperty]] (P, Desc)
  ...
  20. Else targetDesc is not undefined,
a.  If IsCompatiblePropertyDescriptor(extensibleTarget, Desc ,
targetDesc) is false, throw a TypeError exception.
*b. If settingConfigFalse is true*
*  i. If targetDesc.[[Configurable]] is true, throw a TypeError
exception.*
*  ii. If Desc.[[Writable]] is false and targetDesc.[[Writable]] is
true, throw a TypeError exception.*

NOTE [[DefineOwnProperty]] for proxy objects enforces the following
invariants:

  ...
*  * A property cannot be successfully set to non-configurable,
non-writable if the corresponding own property of the target object is
non-configurable, writable.*

WDYT?

Regards,
Tom

2016-08-08 15:37 GMT+02:00 Claude Pache :

>
> > Le 8 août 2016 à 11:02, Claude Pache  a écrit :
> >
> > Here is another test case, with [[GetOwnPropertyDescriptor]]:
> >
> > ```js
> > var target = Object.seal({x: 2});
> > var proxy = new Proxy(target, {
> >getOwnPropertyDescriptor(o, p) {
> >var d = Reflect.getOwnPropertyDescriptor(o, p)
> >if (d && 'writable' in d)
> >d.writable = false
> >return d
> >}
> > });
> >
> > Object.getOwnPropertyDescriptor(proxy, 'x'); // { value: 2, writable:
> false, configurable: false }
> >
> > Object.defineProperty(proxy, 'x', { value: 3 })
> >
> > Object.getOwnPropertyDescriptor(proxy, 'x'); // { value: 3, writable:
> false, configurable: false }
> > ```
> >
> > IMHO, the most robust fix is the following: Both the
> [[DefineOwnProperty]] and the [[GetOwnPropertyDescriptor]] contain the
> following check:
> >
> > * If IsCompatiblePropertyDescriptor(extensibleTarget, resultDesc,
> targetDesc) is false, throw a TypeError exception.
> >
> > I think there should be also the following check (except when targetDesc
> is undefined, in which case another appropriate check is used):
> >
> > * If IsCompatiblePropertyDescriptor(extensibleTarget, targetDesc,
> resultDesc) is false, throw a TypeError exception.
> >
> > That would replace the weaker adhoc check about the [[Configurable]]
> attribute (search for settingConfigFalse) in those algorithms.
> >
> > (Alternatively, in order to avoid double checks, define an
> AreBothWaysCompatiblePropertyDescriptors(extensibleTarget, desc1, desc2)
> abstract operation.)
> >
> > —Claude
> >
>
> Looking closer, it seems that using IsCompatiblePropertyDescriptor is in
> fact an overkill, because we probably don’t want the special case of
> conditionally mutable [[Writable]] attribute for nonconfigurable properties.
>
> That is, I think that the following condition must hold: If either the
> target has a nonconfigurable property, or the proxy claims to have a
> nonconfigurable property, then every attribute of the property descriptor
> claimed by the proxy must be identical to the 

Re: Operating with arbitrary timezones

[peter miller]

On Fri, 05 Aug 2016 22:30:28 +0100, Tab Atkins Jr. 
wrote:

Much of what follows is wanton pedantry, for which I apologise. ;)

I would disagree. Time isn't useful without a point in space (space and  
time
should be looked at as one thing, not two) and since the Date object  
tracks

it internally as UTC it has a default space.


This is incorrect. It tracks a UTC timestamp; the current time as I
write this is 1470432591121 milliseconds since the epoch, and that's
true regardless of where you are on the planet.


I suspect you've dropped 36s from that count or used 1st January 1970 0h  
0m 36s as your epoch.  I might be wrong. But if you have, it's because  
Universal Time is a "rotational timescale": it measures the angle of a  
fictitious point in the sky (U) relative to the prime meridian and not a  
linear count of seconds. The IERS (International Earth Rotation and  
Reference Systems Service) measures the angle of U and issue "Universal  
Time" (UT1). With UTC being kept within one second of UT1 via leap seconds  
(next one at the end of year).


The value an observer measures for U, called UT0, really does depend on  
their exact position on the surface of the earth. That has to be adjusted  
for. That said, UT1/UTC are notionally the same for us all. And I know  
that's what you were saying. Like I said, I'm showing off my very hard won  
knowledge.


And I might as well point out UT is defined on the earth's surface. It's  
affected by gravity.



Timezones are a *display* concept - they affect how you parse
human-readable strings into timestamps, and how you display a
timestamp as a human-readable string.  This is similar to the
distinction between Unicode values and strings encoded in UTF8.


Sure, calendar dates (year, month and day) are a human-friendly way of  
displaying the number rotations of U over a meridian.


But I think timezones represent a change in meridian. I believe in the  
olden days people would set their watches to a local meridian. (I'm  
reading Verne's _Mysterious_Island_ at the moment
and it contains a reference to a chronometer set to the Washington  
meridian.)  And while the "timezones" we use in modern civil life are a  
political construct, I suspect a timezone is still saying display the  
transits of U over such-and-such a meridian; it's a shift in longitude,  
not directly a shift in time.



As a final unrelated comment, I wonder whether 20.3.1.1 should explicitly  
define javascript time values to be:


`d * 8640 + ms`

Where `d` is the number of whole UTC days elapsed since midnight 1 January  
1970 and `ms` is the number of milliseconds elapsed since the start of  
current UTC day, with the value of `ms` being implementation defined close  
to a leap second - and possibly diverging from thousandths of an SI second.


I think that's what the existing standard is trying to say but the current  
phrasing feels wrong, and the above makes clear that timevalues are a  
construct used to represent UTC not a count of millseconds since epoch  
(which javascript dates can never be because they exclude the 36---soon to  
be 37---leap seconds).


Peter

PS: Can we not add underscores to numbers? Would allowing 86_400_000 break  
the web?

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Object.freezing proxies should freeze or throw?

[Claude Pache]

> Le 8 août 2016 à 11:02, Claude Pache  a écrit :
> 
> Here is another test case, with [[GetOwnPropertyDescriptor]]:
> 
> ```js
> var target = Object.seal({x: 2});
> var proxy = new Proxy(target, {
>getOwnPropertyDescriptor(o, p) {
>var d = Reflect.getOwnPropertyDescriptor(o, p)
>if (d && 'writable' in d)
>d.writable = false
>return d
>}
> });
> 
> Object.getOwnPropertyDescriptor(proxy, 'x'); // { value: 2, writable: false, 
> configurable: false }
> 
> Object.defineProperty(proxy, 'x', { value: 3 })
> 
> Object.getOwnPropertyDescriptor(proxy, 'x'); // { value: 3, writable: false, 
> configurable: false }
> ```
> 
> IMHO, the most robust fix is the following: Both the [[DefineOwnProperty]] 
> and the [[GetOwnPropertyDescriptor]] contain the following check:
> 
> * If IsCompatiblePropertyDescriptor(extensibleTarget, resultDesc, targetDesc) 
> is false, throw a TypeError exception.
> 
> I think there should be also the following check (except when targetDesc is 
> undefined, in which case another appropriate check is used):
> 
> * If IsCompatiblePropertyDescriptor(extensibleTarget, targetDesc, resultDesc) 
> is false, throw a TypeError exception.
> 
> That would replace the weaker adhoc check about the [[Configurable]] 
> attribute (search for settingConfigFalse) in those algorithms.
> 
> (Alternatively, in order to avoid double checks, define an 
> AreBothWaysCompatiblePropertyDescriptors(extensibleTarget, desc1, desc2) 
> abstract operation.)
> 
> —Claude
> 

Looking closer, it seems that using IsCompatiblePropertyDescriptor is in fact 
an overkill, because we probably don’t want the special case of conditionally 
mutable [[Writable]] attribute for nonconfigurable properties.

That is, I think that the following condition must hold: If either the target 
has a nonconfigurable property, or the proxy claims to have a nonconfigurable 
property, then every attribute of the property descriptor claimed by the proxy 
must be identical to the corresponding attribute of the property descriptor of 
the target.

—Claude


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Ignoring arguments

[Cyril Auburtin]

Just bumping this up

Calling `foo(1)` where foo is defined with 3 arguments, lets the 2 others
undefined, this behavior is already a bit magic and similar to the behavior
of an array, so I still think foo(a,,b,,,c) should be like
foo(...[a,,b,,,c])

Other example:
```
var m=new Map([[1], [2,], [3,7]]) // Map {1 => undefined, 2 => undefined, 3
=> 7} // here commas fantasies are allowed in arrays
m.set(3) // Map {1 => undefined, 2 => undefined, 3 => undefined} // setting
implicitely value as undefined
m.set(3, ) // not allowed, which should be m.set(...[3,])
```

and again, it would help for callbacks too, `something( ( , , thirdArg) =>
{} )`

I saw this https://jeffmo.github.io/es-trailing-function-commas/, it seems
like a sub-case

2016-05-29 23:07 GMT+02:00 Renki Ivanko :

> One more similarity is that both function parameters and destructuring
> allow default values: (foo = 1) vs [foo = 1].
>
>
>
> On Sun, May 29, 2016 at 11:56 PM, Cyril Auburtin  > wrote:
>
>> Since functions arguments is an array under the hood, they could 'more
>> behave the same'
>>
>> Both function arguments and arrays accept spreading: *[1, 2, ...args] *
>>  and *fn(1, 2, ...args)*
>>
>> a function definition like *(,i) => {}*, would be the equivalent of *var
>> [,i] = arguments*
>>
>> an invocation *fn(,,i)* would be the equivalent of *[,,i]*
>>
>> It's possible with *(...[,i]) => {}, (_,i)=>{} *like Renki said, but
>> slightly less simply
>>
>> Are there possible issues with that 'extension' of function syntax?
>>
>>
>> 2016-05-29 21:32 GMT+02:00 Renki Ivanko :
>>
>>> You could stop with "rare"; having to make up unused names is an obvious
>>> smell in comparison.
>>>
>>> ```js
>>> foo(UNUSED1, UNUSED2, x)
>>>
>>> foo(_, __, x)
>>>
>>> foo(,, x)
>>>
>>> foo(...[,, x])
>>> ```
>>>
>>> The latter is shorter and more explicit and would not be any more
>>> confusing if it became common.
>>>
>>>
>>> On Sun, May 29, 2016 at 8:46 PM, Bob Myers  wrote:
>>>
 Eliding array elements is not "similar" to eliding function formal
 parameters. The latter is extremely rare, hardly readable, confusing,
 bug-prone, and unnecessary because there is already a "standard way" which
 is to use any old parameter name you want:

 ```js
 function foo(UNUSED1, UNUSED2, x)
 

 Most linters will not complain, or there are ways to shut them up if
 they do.

 If you want to throw away an argument, just throw it away.

 ```js
 function skipFirstParam(fn) { return ((first, ...args) => fn(...args));
 }

 `[1,2,3,4].map(skipFirstParam(i => i));

 ```

 Or use Renki's solution.

 Bob


 On Sun, May 29, 2016 at 9:23 PM, Cyril Auburtin <
 cyril.aubur...@gmail.com> wrote:

> Similarly to:
>
> `var [,x,,y] = [1,2,3,4,5,6];`
>
> I think it could be interesting to let a field empty in function
> arguments
>
> `[1,2,3,4].map( (,i) => i )`, `Array.from({length:10}, (,i) => i )`
>
> `function test(a,,b) { }`
>
> (but that would alter the current parsing, that doesn't allow it)
>
> Currently I often use `_` as a way to mark ignored fields, but when
> there are more than 1 you need another identifier. A standard way would be
> interesting rather
>
> ___
> 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


>>>
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Object.freezing proxies should freeze or throw?

[Claude Pache]

Here is another test case, with [[GetOwnPropertyDescriptor]]:

```js
var target = Object.seal({x: 2});
var proxy = new Proxy(target, {
getOwnPropertyDescriptor(o, p) {
var d = Reflect.getOwnPropertyDescriptor(o, p)
if (d && 'writable' in d)
d.writable = false
return d
}
});

Object.getOwnPropertyDescriptor(proxy, 'x'); // { value: 2, writable: false, 
configurable: false }

Object.defineProperty(proxy, 'x', { value: 3 })

Object.getOwnPropertyDescriptor(proxy, 'x'); // { value: 3, writable: false, 
configurable: false }
```

IMHO, the most robust fix is the following: Both the [[DefineOwnProperty]] and 
the [[GetOwnPropertyDescriptor]] contain the following check:

* If IsCompatiblePropertyDescriptor(extensibleTarget, resultDesc, targetDesc) 
is false, throw a TypeError exception.

I think there should be also the following check (except when targetDesc is 
undefined, in which case another appropriate check is used):

* If IsCompatiblePropertyDescriptor(extensibleTarget, targetDesc, resultDesc) 
is false, throw a TypeError exception.

That would replace the weaker adhoc check about the [[Configurable]] attribute 
(search for settingConfigFalse) in those algorithms.

(Alternatively, in order to avoid double checks, define an 
AreBothWaysCompatiblePropertyDescriptors(extensibleTarget, desc1, desc2) 
abstract operation.)

—Claude

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Try/catch conditional exceptions in light of generators

[Vlad Fedosov]

Hi! Is there is any way to push this proposal forward?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss