Remove Object#=~ and Object#!~ #5910
Conversation
|
I'm sure you'll realise why this was the way it was as you try to make CI pass. |
src/spec/expectations.cr
Outdated
| @@ -170,7 +170,7 @@ module Spec | |||
| end | |||
|
|
|||
| def match(actual_value) | |||
| actual_value =~ @expected_value | |||
| actual_value.responds_to?(:=~) && actual_value =~ @expected_value | |||
There was a problem hiding this comment.
Not really a fix: you moved the "returns nil" logic from global operators to a specific use case.
The fact that the match expectation is called with non String nor RegExp objects may be proof that the global behavior is actually good?
|
@ysbaddaden True, I was just checking f there would be any other failures. It seems it is just missing Although the issue is that Both are not optimal. I don't know if there is a better way. I still would like to avoid having |
|
sure nil is pretty common but it's not really specil compared to any other class. We should keep this as-is. I vote close. |
|
I also vote to close it. I'll explain (a bit more) why in #5829 |
Fixes #5829
Overloads for
Regex#=~are restricted to receiveString | Niland forString#=~to receiveRegex | Nil.#!~is re-added as instance method in both classes accepting the same overload.It could be up for debate to leave
Object#!~to avoid having individual definitions in classes implementing=~. But this would end up in a similar issues as #3450I'm also not entirely sure about the type safety of
Regex#=~andString#=~. Should their argument really be nilable, or allow onlyString,Regextype, respectively? On the other hand, they could even receive any type and just returnnillike it is the case right now.