[[DefineOwnProperty]] wording nit
On Sat, Sep 12, 2009 at 5:08 AM, Jeff Walden <jwalden+es at mit.edu> wrote:
"If a field is absent then the result of any test of its value is logically false."
I believe there are two plausible ways to interpret this: any evaluation of desc.[[Something]] when there is no [[Something]] field returns the value false, or the result of any comparison which evaluates desc.[[Something]] must be false.
The second is certainly not how I would have interpreted it cold. It doesn't seem like a reasonable interpretation of the text.
The difference shows up in step 7b, whose wording is:
"Reject, if the [[Enumerable]] fields of current and Desc are the Boolean negation of each other."
Under the first interpretation, if there is no [[Enumerable]] field in Desc, then never Reject.
Under the second interpretation, if there is no [[Enumerable]] field in Desc, and if current.[[Enumerable]] is true, then Reject.
I think you have the two interpretations reversed here; under the second interpretation (the one that doesn't seem reasonable to me), if [[Enumerable]] is missing, we never Reject.
Past email to this list makes clear the first interpretation was the desired one.
(assuming you mean the second interpretation)
Yow. This is very unintuitive. To me, the spec seems to say the opposite of what's intended here.
Perhaps modifying step 7b to explicitly say "Reject, if [[Enumerable]] is present in Desc and...", is a less arcane approach to fixing this. (That might not be the only change needed though.)
Thanks for reading carefully.
There is already a fix to the note listed in the errata at es3.1:es3.1_proposal_working_draft but looking at it again, I think that both interpretations are contextually assumed for different lines of the algorithm. I'll make a pass over it to try to eliminate any such ambiguity and update the errata later today.
The new errata is now available at es3.1:es3.1_proposal_working_draft
On 17.9.09 12:15 , Jason Orendorff wrote:
The difference shows up in step 7b, whose wording is:
"Reject, if the [[Enumerable]] fields of current and Desc are the Boolean negation of each other."
Under the first interpretation, if there is no [[Enumerable]] field in Desc, then never Reject.
Under the second interpretation, if there is no [[Enumerable]] field in Desc, and if current.[[Enumerable]] is true, then Reject.
I think you have the two interpretations reversed here; under the second interpretation (the one that doesn't seem reasonable to me), if [[Enumerable]] is missing, we never Reject.
Er, yes, I did.
Past email to this list makes clear the first interpretation was the desired one.
(assuming you mean the second interpretation)
The one I meant was "the result of any comparison which evaluates desc.[[Something]] must be false". I'm not going to try to number this, given the mixup in the email. :-)
Yow. This is very unintuitive. To me, the spec seems to say the opposite of what's intended here.
I don't disagree!
Perhaps modifying step 7b to explicitly say "Reject, if [[Enumerable]] is present in Desc and...", is a less arcane approach to fixing this. (That might not be the only change needed though.)
This isn't what I'd thought we meant, but it seems to be the newly-adopted change in errata, and indeed I prefer it to the one I thought we meant -- much more intuitive.
-----Original Message----- From: es-discuss-bounces at mozilla.org [mailto:es-discuss- bounces at mozilla.org] On Behalf Of Jeff Walden ...
Perhaps modifying step 7b to explicitly say "Reject, if [[Enumerable]] is present in Desc and...", is a less arcane approach to fixing this. (That might not be the only change needed though.)
This isn't what I'd thought we meant, but it seems to be the newly- adopted change in errata, and indeed I prefer it to the one I thought we meant -- much more intuitive.
Yes, that was always the intent. Think about it from the perspective of Object.defineProperty. If you are defining a new property a missing attribute is supposed to mean use its default value. If you are redefining an existing property a missing attribute is supposed to mean keep the existing value. Most of the logic in [[DefineOwnProperty]] is rejecting invalid or inconsistent redefinitions.
"If a field is absent then the result of any test of its value is logically false."
I believe there are two plausible ways to interpret this: any evaluation of desc.[[Something]] when there is no [[Something]] field returns the value false, or the result of any comparison which evaluates desc.[[Something]] must be false. The difference shows up in step 7b, whose wording is:
"Reject, if the [[Enumerable]] fields of current and Desc are the Boolean negation of each other."
Under the first interpretation, if there is no [[Enumerable]] field in Desc, then never Reject.
Under the second interpretation, if there is no [[Enumerable]] field in Desc, and if current.[[Enumerable]] is true, then Reject.
Past email to this list makes clear the first interpretation was the desired one. Here's a wording proposal which, I think, admits only the first interpretation:
"If a field is absent, then the result of any test which uses that field's value is logically false."