-
Notifications
You must be signed in to change notification settings - Fork 553
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support equality operators with lists #606
Comments
Because as this, it does object instance comparison. Code is missing for the support. |
I'll add that the culprit is |
Maybe if it can't test for equality it should raise an exception. It could lead to some difficult to find bugs if people assume that they can test the equality of two lists, but find that their code doesn't do what they expect; things shouldn't fail silently, unless we make it explicit. |
I suppose it depends on the intended semantics, but the current behaviour doesn't bother me. Each list is a different object in the heap so I wouldn't consider them to be the same object, even if their contents is "equal". I would expect the following to print
To do as this issue suggests, equality operations would have to do deep inspection of the whole list contents (adding to the operational complexity). Would the same semantics extend to maps? What about deeply-nested lists? |
Well to me == is the good place. There is some *same* object function (i
would prefer === but that is another subject) that has the same object
sementic.
I have a whole new branch, that need still a lot love, but I added <=> aka
starts his operator, that is an even better solution to the list equality
question.
|
I'm also not a fan of deep/expensive operations on syntax level. There are functions though! We don't need to overload syntax for operations on values when functions are a unit of work.
|
Isn't |
All methods can be overloaded, even the critical ones (if there is any).
There is no real check in the compiler for that.
|
Are there any other scripting languages where a simple equality test of lists does a deep comparison? I think it's really uncommon at best, due to problems mentioned by @underscorediscovery. Of course we know it from C++, but values are not pointers there unless written so explicitly, so it's clear when you do a pointer comparison or a deep comparison. |
I think most language does collection equality using the *real* equality
operator. The nuance is that here *==* is the *real* equality, while
*same(_)* is the *simple* test.
|
Quick aside: It looks like the terms for what we are discussing are "physical" and "structural" equality. Wren's current An operator for testing structural equality might be useful, but it shouldn't replace the existing semantics of |
I disagree with that, for me as == is a *structural* equality, it is
expected to be expensive and slow, and defaults to *physical* equality
which is dumb simple and fast.
|
It doesn't do this in Java, C#, Lua and JavaScript. Neither does it work like that in C++ or C if you're dealing with pointers (which is essentially what Wren object handles are). I just found Python and Ruby do a deep comparison, but Python provides " In any case I think it's not easy to say what "most languages" do, and by extension it's not easy to say what |
It all depends on what you consider to be the source of equality. For me in java, .equals() seems to be for me a better source of equality than == since it can be overloaded. If all is a question of having a physical and structural equality, for me === and == are the ideal candidates it is only a question to have them as operators. This relate to the fact that I'm a big fan of the <=> operator. That would make 3 operators of 3 symbols (===, !==, <=>). |
I feel like there is already |
Currently the code
[1,2] == [1,2]
returnsfalse
. I can't find anything in the documentation as to why this would be. Equality on lists should really be supported.The text was updated successfully, but these errors were encountered: