consistency between in_check ops and equality/comparison ops ?

[moodymudskipper]

consistency between in_check ops and equality/comparison ops ?

[moodymudskipper]

Also what would be the expected output for list(list(1,2)) %in{}% list(list(1,2), 3) ?

I believe we should unlist by default the rhs, it seems to be what range() does anyway :

range(list(1,list(3,4)))
#> [1] 1 4

Then I think failing like == does is good enough so we avoid opening a new can of worms and can aim to have everything consistent with == rather than %in%, does that sound right ?

list(list(1,2)) %in% list(list(1,2), 3)
#> [1] TRUE
list(list(1,2)) == list(list(1,2), 3)
#> Error in list(list(1, 2)) == list(list(1, 2), 3): comparaison de ces types non implémentée
list(1,2) %in% list(1, 3)
#> [1]  TRUE FALSE
list(1,2) == list(1, 3)
#> Error in list(1, 2) == list(1, 3): comparaison de ces types non implémentée
c(1,2) == list(1, 3)
#> [1]  TRUE FALSE
c(1,2) %in% list(1, 3)
#> [1]  TRUE FALSE
list(1,2) == c(1, 3)
#> [1]  TRUE FALSE
list(1,2) %in% c(1, 3)
#> [1]  TRUE FALSE

^{Created on 2019-08-18 by the reprex package (v0.3.0)}

[moodymudskipper]

I've pushed a few changes, including making %in{}% consistent, other check ops were ok, and I made tests for those

[karoliskoncevicius]

Making it consistent with == sounds about right to me!.

Also I am wondering if there is a way to make them adhere to "group generics". Specifically "Group Ops" in ?groupGeneric

[moodymudskipper]

Group "Ops":
... (arithmetic ops)
"==", "!=", "<", "<=", ">=", ">"
... (on unary ops)
The classes of both arguments are considered in dispatching any member of this group. For each argument its vector of classes is examined to see if there is a matching specific (preferred) or Ops method. If a method is found for just one argument or the same method is found for both, it is used. If different methods are found, there is a warning about ‘incompatible methods’: in that case or if no method is found for either argument the internal method is used.

I think group generics allow identical(iris < 3, 3 > iris) to be TRUE, I think it would be confusing in our case, you would want "^foo" %in~% x to work as x %in~% "^foo" ? Or maybe I'm missing something.

Note that the data.frame methods for the comparison ("Compare": ==, <, ...) and logic ("Logic": & | and !) operators return a logical matrix instead of a data frame, for convenience and back compatibility.

This is implemented in our operators already

If the members of this group are called as functions, any argument names are removed to ensure that positional matching is always used.

we could do that, but I don't see the point, the positional matching is used by primitives for speed as far as I understand, and operators are almost never invoked as functions.

[karoliskoncevicius]

What I meant is that if somebody writes a custom S3 (or S4 for that matter) object and implements Ops.class <- function(e1, e2) { ... } that it would extend automatically to the operators in this package as well.

Maybe it doesn't make much sense, since the e2 in our case is not an object of a new class.

Yeah let's drop this. Bad idea.

[moodymudskipper]

regex ops must be made consistent as well + tests and then we can close this

[moodymudskipper]

regex ops defined and should behave ok, tests to design still

[moodymudskipper]

closing this as we have an issue about unit tests
#7