On Thu, Nov 13, 2008 at 5:38 PM, Allen Wirfs-Brock < [EMAIL PROTECTED]> wrote:
> *From:* Mark S. Miller [mailto:[EMAIL PROTECTED] > >>I also think the SameValue name is misleading as it is really just a > StricterEquality test and not a identical value test. This name confusion > is probably what caused it to be edited into [[DefineOwnPropety]]. > > >As DavidSarah says, SameValue *is* an identical value test. The only > difference between === and an identical value test is NaN and -0, which are > therefore called out as special cases in SameValue. > > > > There is at least one case where it is not an identical value test. That > is the case where there are multiple implementation dependent NaN encoding > as is explicitly allowed for by the specification. Even though == and === > (and SameValue) does not distinguish them they are potentially > distinguishable by a host object or otherwise using external code ad this > distinction can be reported back to ECMAScrpt code. As such, they don't > meet my usual criteria as being identical values and in particular I would > consider an apparent attempt to use Object.defineProperty to replace a > readonly NaN value with a different NaN value encoding to be a violation of > the [[Writable]]: false constraint. That's why I don't believe it is > appropriate to use SameValue in [[DefineOwnProperty]] . > [...] > > As I've said above, I think observably different via calls to external code > is enough to call into question the sameness of two values. This is > particularly the case when we are dealing with primitive data types like > binary and decimal floats that routinely flow across language or other > domain boundaries. I'm not particularly concern about language specific > types and values (for example, a language specific closure type) that is > unlikely to be passed or have meaning across such boundaries. Obviously, an > implementation should be free use alternative encoding for the "same" value > but it probably needs to cannonicalize such representations when passing > them outside its private implementation domain. Unless we require > canonicalization for primitive values on calls to/from host objects we > probably need to be a little less parochial about what is observable. > Well, I'm glad at least to see realization of the significance of this issue, although I arrive at a different conclusion. In ES itself (ignoring decimal for now), there really is only one NaN value. If a call to [[DefineOwnProperty]] may be rejected because a presented NaN was not identical enough to a stored NaN, even though they do not differ in any way detectable or explicable to a JavaScript programmer, then we may as well instead specify that [[DefineOwnProperty]] just randomly succeeds or fails at the implementation's whim. I do not think it is productive to imagine that we can evade our responsibility as language designers to say what the potentially distinguishable values are in our semantic state. No such decision will be satisfying. Any decision will have unfortunate consequences. But not deciding is worse. -- Cheers, --MarkM
_______________________________________________ Es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
