[[DefaultValue]] - When Is toString Not an Object?
The question I have is about the internal [[DefaultValue]] function.
When [[DefaultValue]] is called with hint String, it first looks for a
toString method. This seems strange because every native object would
have a toString method in the prototype chain.
To get the [[DefaultValue]](String) to call O's valueOf, it is
necessary to shadow any toString method with a primitive value.
({0 : 12})
[{toString:1,valueOf:function(){return 0;}}]
Results
Firefox 3, Webkit:
12
Opera 9.5
Error
Why is it this way?
When the [[DefaultValue]] method of O is called with hint String, the
following steps are taken:
1. Call the [[Get]] method of object O with argument toString.
2. If Result(1) is not an object, go to step 5.
3. Call the [[Call]] method of Result(1), with O as the this value
and an empty argument list.
4. If Result(3) is a primitive value, return Result(3).
5. Call the [[Get]] method of object O with argument valueOf.
6. If Result(5) is not an object, go to step 9. 7. Call the [[Call]] method
of Result(5), with O as the this value and an empty argument list.
8. If Result(7) is a primitive value, return Result(7).
9. Throw a TypeError exception.
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: use decimal
On Sep 17, 2008, at 10:13 PM, Mark S. Miller wrote: On Wed, Sep 17, 2008 at 6:50 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: I agree that typeof 1.5m == typeof 1.1m. However, I do not agree that 1.1m == 1.1. These should be !=, since they represent distinct real numbers. It seems to me that Brendan said 1.1m != 1.1 and did not question this. Brendan, please correct me if I misrepresent your argument. I took Brendan to be saying that 1) If typeof 1.1m were 'number' then we'd be obligated to have 1.1m == 1.1. 2) We want 1.1m != 1.1. 3) Therefore, typeof 1.1m must not be 'number'. I disagree with #1 and thus #3. Here is what I wrote: Without use decimal, typeof 1.1m must not be number to preserve this same invariant [that a === b = typeof a == typeof b a == b]. Otherwise (without use decimal) 1.5m == 1.5 but 1.1m != 1.1, so without making typeof 1.5m != typeof 1.1m, we cannot have typeof 1.5m == number. Please expand your syllogistic reasoning: Major premise #1: a == b Minor premise #1: typeof a == typeof b Conclusion #1: a === b (you can switch == and === above -- the implication goes both ways and choice of == or === for typeof a OP typeof b does not matter since typeof's result is of string type.) Major premise #2: 1.5m == 1.5 Minor premise #2: typeof 1.5m == number (your position, IIUC) Conclusion #2: 1.5m === 1.5 (by Conclusion #1 and ES1-3 (which define typeof 1.5 == number)) Counter-example: 1.1m != 1.1 but typeof 1.1m == typeof 1.1 in your proposal (again IIUC) This is a for-all problem. If there exists some double value x such that, for the decimal form y spelled literally using the same digits but with an 'm' suffix, x != y, yet typeof x == typeof y, then typeof must depend on whether its operand value converts losslessly to decimal from double and double from decimal. This is broken -- typeof should depend on type, not value. Hence my position (Waldemar's too) that typeof 1.1m == typeof 1.5m typeof 1.1m == decimal. However, with the introduction of decimal, we've got cohorts galore. 1.1m has a different operational behavior than 1.1000m, but we've agree they should be ===. With the introduction of decimal, === no longer approximates a test of operational equivalence, and we still need such a test. === does approximate operational equivalence apart from significance. Right? (I'm asking because I could be wrong, not rhetorically!) 0/-0 != 0/0. Does it thus seem wrong that -0 === 0? Well, yes, actually it does seem wrong to me, but we all accept that particular wrongness. This is just more of the same. A lot more. Two wrongs don't make a right. One exception to the rule is better than two, or 2^53 or larger. /be ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: use decimal
On Sep 17, 2008, at 7:48 PM, Sam Ruby wrote: Anybody care to mark up what they would like to see the following look like? http://intertwingly.net/stories/2008/09/12/estest.html Shipt it! (Not in ES3.1, certainly in Firefox 3.1 if we can... :-) /be ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: use decimal
On Sep 17, 2008, at 10:06 PM, Mark S. Miller wrote: 0/-0 != 0/0. Does it thus seem wrong that -0 === 0? Well, yes, actually it does seem wrong to me, but we all accept that particular wrongness. This is just more of the same. A lot more. Two wrongs don't make a right. One exception to the rule is better than two, or 2^53 or larger. apart from somthing like significance is a huge new set of exceptions. A large enough set that we can no longer understand === as approximating operational equivalence. If instead we understand === to be asking whether two operands are cohorts, and we define cohorts to be those numeric values that exactly represent a given real number, then 1) -0 vs 0 is no longer irregular 2) We can explain why 1.5 === 1.5m === 1.5000m 3) We can explain why 1.1 !== 1.1m. I think it is a tenable position that 1.5m === 1.5000m based on the cohort concept, since performing the same operation on both will give answers that are in the same cohort equivalence class. But 1.5 / 10.0 != 1.5m / 10.0, and indeed, the answers would not even be in the same cohort. A notion of 'cohort' equivalence class based on correspondence in the abstract to the same real number but divorced from the actual semantics of the programming language strikes me as incoherent. I think such a notion of equivalence class only makes sense if performing identical operations on members of the same cohort gives answers which are in the same cohort. As a reductio ad absurdum, consider that we can place ECMAScript strings in one-to-one correspondence with arbitrary precision integers by considering them as base 2^16 numbers, but surely no one would argument that this implies 00 === 3145776L. That's because in defining a type, it is not just the set of represented values that matters for type equivalence, but also behavior of operations on that type. Regards, Maciej ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
