OK, I now see the difference between SameValue and StrictEquality.
SameValue(NaN,NaN) is true and StrictEquality(NaN,NaN) is false. Assuming that
we really need this distinction, rather than duplicating "code" I would define
one in terms of the other with an additional predicate to handle the NaN
distinction.
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]].
Finally, I understand the thinking behind using SameValue in
Array.prototypeindexOf and Array.prototype.lastIndexOf but do we really want to
introduce yet another concept of "equality" into the language just to these
functions. If NaN comparision is a special case for these function might not
there be other special cases of user defined objects? To me, a better design
would be to add a optional third argument to those functions which is a
closure that provides the comparison function. That way the default comparison
could be === (or == if that makes more sense) and you would search for a NaN by
saying something like: [1,2,NaN,3].indexOf(NaN,0,function(x,y) {return
IsNaN(x)}). Of course, the first argument is not strictly necessary in this
formulation so an even cleaner alternative might me findIndexOf(callbackfn [,
fromIndex]) so you could express it as [1,2,NaN,3].FindIndexOf(function(x,y)
{return IsNaN(x)})
So, what do the "in the wild" implementations of indexOf do? Do they do a ===
comparison or do they do the equivalent of the proposed SameValue function?
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Allen Wirfs-Brock
Sent: Thursday, November 13, 2008 8:27 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Issues relating to 9.11 The SameValue Algorthm
The SameValue algorithm was recently added as section 9.11. I think you did or
requested it. Unless I'm missing something, this algorithm appears to compute
the same result as the Strict Equality Comparison Algorithm in section 11.9.6.
Am I missing something?? Is there some reason we need both of these?
One of the places that a call to SameValue was inserted was into the algorithm
of [[DefineOwnProperty]]. I believe that this change unintentionally changes
at least one part of that algorithm. The problem is in step 10.a.ii.1 which is
now written to do a SameValue comparison between the existing [[Value]]
attribute of a property and the [[Value]] attribute of the property descriptor.
This is in a clause that is predicated by the [[Writable]] field of the
property being false. The intent of this is that ECMAScript level could can
get a property descriptor for some readonly property (the property descriptor
object will include a value: property) modify some attributes in the descriptor
(for example, the configurable attribute) and then use that same descriptor in
a call to defineProperty which ultimately uses [[DefineOwnProperty]]. This is
OK for a readonly property as long as the value in the descriptor is the exact
same value as the current value of the property (in other words the value is
not being changed). The problem with SameValue is that it does not test for the
exact same value. Its use in [[DefineOwnProperty]] would, for example, let a
read only +0 be replaced with a -0 or replace a NaN with one implementation
dependent encoding with a NaN with another encoding. I have no idea what
Decimal compareQuietEqual actually does but I would also assume that it does
something other than an exact same encoding comparison.
The other uses of SameValue in [[DefineOwnProperty]] is probably ok as there
are operating upon getter and setter function values and there is a
precondition that these values will be either undefined or a IsCallable object.
I actually don't think there was necessarily a problem with the original
algorithm that simply said that they must be the "same value". In this context,
"value" is as defined in Section 8 and "same" has its common English meaning.
It does mean "equal" or "equivalent".
_______________________________________________
Es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
