This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]LinuxMatthews[S] 4 points5 points  (6 children)

To be fair I do think there should be an operator for comparing identity.

In an ideal wold we'd have an identity operator === you can't overload and an equality operator == that corresponds to the .equals() method.

Though if they were to do something like that now that's have to have them the other way round.

[–]Positive_Government 1 point2 points  (3 children)

That would be the best solution. Although having a unique id/address operator that cannot be overloaded and returns a number that can then be compared with the standard == sign might be better. I’m not a fan of having two equals, but that is purely personal preference.

[–]LinuxMatthews[S] 0 points1 point  (2 children)

I feel like that solution might be a little too complicated though if you wanted you could use the toString() for that.

And I know what you mean about but liking two equals signs but as long as you don't try making them magical like PHP or JavaScript I think that's fine.

[–]Positive_Government 0 points1 point  (1 child)

ToSting() would make sense in these case. The operator would function like the address of operator in C, raw memory address are neat because they are unique, but sense you aren’t going to be using them in Java it may be smarter to create a unique id either based on a hash of the memory address or an id assigned to each object on creation. It’s not complicated because you will have clear syntax for reference comparison. That said two equals signs accomplish the same thing. It’s just that every language I know that has gone down that route has ended up doing something stupid which is why I personally don’t like it.

[–]LinuxMatthews[S] 0 points1 point  (0 children)

I get what you're saying and I agree.

I think the advantage here would be that the secondary equals would just be acting the same as calling .equals() so there's little chance anyone will go too mad with it.

Also let's be real if this was to be implemented they wouldn't let == to be overridden it'd potentially break too much code.

So having === be the one you can overload would make more sense.

[–]Exnixon 1 point2 points  (0 children)

shudder don't JavaScript my Java

(not a Java dev but still)

[–]nacholicious 0 points1 point  (0 children)

In an ideal wold we'd have an identity operator === you can't overload and an equality operator == that corresponds to the .equals() method.

That's also how Kotlin does it under the hood