Too complicated. And anything that would massively change most existing code is simply a no-go.
| |
Lummox JR wrote:
Screw it! Operator overloading is a go. This will be a great boon to my (occasionally hypothetical) arithmetic libraries. | |
So you'd rather make the language a mess instead?
If you separate ~= and == here's what's gonna happen: every sane man working in BYOND is gonna switch to using ~=, unless it has some dumb performance implication. If you keep the divide either is gonna become useless and a historical accident. Seriously the added confusion of "crap I used == instead of ~= is NOT worth it. Also ~= is a terrible name for it because it conflicts with Lua's ~=. | |
PJB3005 wrote:
Also ~= is a terrible name for it because it conflicts with Lua's ~=. Conflicts in exactly what sense. Also, many languages have multiple equivalence operators. From the way this is going, it sounds like the design behavior will be that == is a comparison on whether two objects are actually the same versus whether two objects are (in the case of matrices and lists) equivalent in the sense that they have the same data in the same order. This seems quite natural to me. | |
What Lua does is its own business.
Because equivalence checking is by nature more of a performance drain than equality checking, and equality is all people care about most of the time anyway, I don't see ~- taking over. Now I will say JavaScript does this a bit differently. They have === and !==, which are like super versions of == and !=, but they do that because JavaScript allows "1" == 1. That is, their regular equality operator is a limited equivalence operator; it does not check if two objects are equivalent, but it does allow a string that represents a number and the number itself to be considered equal. For this reason they have === for stricter checking. Currently in BYOND, the only exception == carves out from perfect equality is that if you're dealing with two numbers, it says -0 and 0 are equal. So unlike JavaScript, DM was always stricter about types when it came to comparisons. The new equivalence BTW will not move it in a JavaScript direction where 1 and "1" are considered alike. The point of this operator, really, besides that it's useful for matrices and shallow checking of lists, is that with operator overloading you frequently want a quick way to tell if two datums are effectively the same, and now this will do that. | |
The issue is that there is no point in overriding ~= if thats not what is commonly used and there is no point in using == if you can't override it.
So everybody will just end up moving to ~= except when they explicitly want == | |
In math, ~ is the common symbol for an equivalence relation (while = is used for equality), so to some extent I think the -= operator makes sense. The problem I have is that it looks too similar to assignment operators. Is there any reason that -- can't be used instead? This would make the analogy between == and -- a little clearer, and be a better analog to !-
| |
Popisfizzy wrote:
Is there any reason that -- can't be used instead? -- is the decrement operator, whether written --A or A-- (pre- and post- decrement respectively), specifically that last one will clash with A -- B | |
Personally I would rather just not have ~= at all. It sounds suspiciously useless.
| |
MisterPerson wrote:
Personally I would rather just not have ~= at all. It sounds suspiciously useless. Approximate equality is particularly useful, as it would allow direct comparison of say, a big integer wrapper object. | |
The math thing kind of informed my decision. That, and I think =~ and !~ would be confused for regex operators.
| |
I'd meant to write ~~ rather than --. I'm on mobile and tapped the wrong symbol looking at a dim screen
| |
What about <>? It's used to determine inequality in BYOND as well, despite being relatively underused in comparison to !=.
| |
That would break backwards compatibility, though in my opinion anyone using it is wrong because they're dumb
| |
I think lummox is on the right side of this
equality and equivalence are two related but very different concepts, and most sensible languages separate the two. The difference being in which one they expose by default in the == operator Give that historically == and != have been equality there's not much choice but to come up with new operators for equivalence and ~= and ~! aren't bad as operators go. | |
Optimumtact wrote:
equality and equivalence are two related but very different concepts Not really... Equality is just the least-coarse equivalence relation. One subsumes the other | |
Exciting stuff
| |
allow programmers to back themselves into a hole if they want by conflating the two.
or make it return a value and then compare the value, as most cases of == overriding is just about de-abstracting the class away.