On 05/10/11 23:06, Brendan Eich wrote:
On Oct 5, 2011, at 7:01 PM, Quildreen Motta wrote:
On 05/10/11 22:05, Brendan Eich wrote:
On Oct 4, 2011, at 7:19 AM, Juan Ignacio Dopazo wrote:
Yes, tools should be better, but they need to start becoming better by
themselves as previous discussions here have noted.
However, there are problems in the language that need to be addressed by both
syntax and APIs. We need:
- A sane way of dealing with equality, identity and basically a lot of what's
in http://wtfjs.com/
Some of that is due to implicit conversions, not any equality-ish operator.
I really never understood people's complaints about equality comparisons in
JavaScript. There are only two operators, with clear and well defined
semantics/use-cases:
`==' (Abstract equality) is used for comparing the value of two objects,
without taking data-structure into account.
This operator is insane due to implicit conversions it does when operand types
are not the same. In such cases it is not an equivalence relation.
I would argue this is not entirely true. It would depend on what you
consider "equivalence". As I said, the way I see the abstract equality
algorithm is that it compares "values" — by which I mean primitive
values, — such that it can't really take into account the data structure
of the operands.
So, `1' equals `"1"' which equals `[1]' which equals
`{toString:function() "1"}' which might equal just about any other
object which `toString' returns "1". In this case, the semantics are
pretty sane (though some might argue about `[1]' and other objects). We
could say it would be analogous to having a book in several different
medias — ebook, paper, audio, etc. Just because the medias are
different, it doesn't mean the contents of the book are.
I have to agree, however, that some of the conversions are not as
intuitive — at first glance — as the ones in the relational operators,
which always convert the operands to the a numeric primitive value.
Perhaps some of the fault of abstract equality's usage might be on the
lack of chaining comparisons, though:
---
// This is not what you'd usually assume it to be, based on mathematical
notation
2 == "2" == [2] // => false
// ...because operations are done this way
(2 == "2") == [2]
→ (2 == ToNumber("2")) == [2]
→ (2 == 2) == [2]
→ true == [2]
→ true == ToPrimitive([2]) // [2].valueOf().toString()
→ ToNumber(true) == "2"
→ 1 == ToNumber("2")
→ 1 == 2
→ false
---
That said, I don't consider the semantics of abstract equality *that*
complex to consider it a problem — there are some recursive conversions,
yes. ToPrimitive might get confusing depending on how toString and
valueOf are defined in the object. That might be a problem or an
interesting feature depending on the particular use-case, considering
how dynamic JS is.
That's not to say it's perfect in every single conversion, but it gets
at least 90% of all the practical use cases right. Other people probably
have a different opinion on this kind of equivalence coming from a
strong or static/strong typed background.
`===' (Strict equality) is used for comparing the value of two objects, taking
data-structure into account.
This operator is fine, unless you want to test (NaN is NaN) or (-0 isnt 0).
There, you need is/isnt.
Is `egal' already in ES.next?
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
