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

Reply via email to