Kevin Smith wrote:
Your point about it being too late to salvage == (vs. ===) is
good, but perhaps with value objects plus further work to disable
implicit conversions, == will make a come-back -- but that's far
down the road.
Work to disable implicit conversions? Can you clarify?
It's a gleam in my eye, at least. Some day we may enable users to choose
to get exception, not toString, on myUrl == "haha". Details TBD, and not
via valueOf/toString hacking (which doesn't quite work).
I'm actually quite wary (so far) of allowing the user to override an
operator whose abstract meaning is already so abstruse.
You've seen the rationale, here it is again:
== is overloadable along with < and <= to cope with unordered values and
to enable common safe comparisons, e.g. 0m == 0.
!= and ! cannot be overloaded, to preserve De Morgan's Laws and other
obvious invariants.
There is no "abstruseness" in x == y when typeof-types match. Even when
they don't, for numeric types, the relationals and == are loose. We
won't change that. Adding value objects should afford new numeric types
the same expressiveness that number has, or usability impairments will
hamper adoption.
If it's ok to test !0 or even 0 == "0" (yes, I know == is not transitive
in full), then 0m == 0 or 0n == 0 should be supported too.
/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss