%>% overlaps with pipe operator from magrittr #87

Closed
noamross opened this Issue Jun 26, 2014 · 9 comments

Comments

Projects
None yet
4 participants
@noamross

The package magrittr is rapidly becoming very popular, and it's central function is pipe operator %>%, which stringi uses as a comparison operator. This means that you can't use both in the same workflow. Would you consider changing the syntax of %>% (and %<%)?

@bartektartanus

This comment has been minimized.

Show comment
Hide comment
@bartektartanus

bartektartanus Jun 26, 2014

Contributor

Every operator in stringi package, like %?% is also available with prefix stri, like %stri?%. Check the example:

"a"%>%"b"
[1] FALSE
"a"%stri>%"b"
[1] FALSE
Contributor

bartektartanus commented Jun 26, 2014

Every operator in stringi package, like %?% is also available with prefix stri, like %stri?%. Check the example:

"a"%>%"b"
[1] FALSE
"a"%stri>%"b"
[1] FALSE
@gagolews

This comment has been minimized.

Show comment
Hide comment
@gagolews

gagolews Jun 26, 2014

Owner

Dear Noam, it's normal that R function names overlap. Unless magrittr and stringi are co-used very often, it's no time for change. As Bartek said, we have the %stri*% aliases. Additionally, magrittr::%<% and stringi::%<% are always unambiguous.

Owner

gagolews commented Jun 26, 2014

Dear Noam, it's normal that R function names overlap. Unless magrittr and stringi are co-used very often, it's no time for change. As Bartek said, we have the %stri*% aliases. Additionally, magrittr::%<% and stringi::%<% are always unambiguous.

@stefanfritsch

This comment has been minimized.

Show comment
Hide comment
@stefanfritsch

stefanfritsch Jul 25, 2014

The problem is that if stringi is loaded after magrittr (which is likely because it's the more specialized package) it ends up with the higher priority.

Writing magrittr::%>% completely defeats the purpose of the pipe (concise and readable code) so the two packages simply don't mix.

Now your usage might even be older but with dplyr, ggvis and whole bunch of other packages going with magrittr that makes stringi more and more of a liability. You said yourself that stringi has alternatives, so couldn't you just remove the %>%?

I like stringi because it makes string handling in R a lot less aggravating but you're just the less general purpose package.

The problem is that if stringi is loaded after magrittr (which is likely because it's the more specialized package) it ends up with the higher priority.

Writing magrittr::%>% completely defeats the purpose of the pipe (concise and readable code) so the two packages simply don't mix.

Now your usage might even be older but with dplyr, ggvis and whole bunch of other packages going with magrittr that makes stringi more and more of a liability. You said yourself that stringi has alternatives, so couldn't you just remove the %>%?

I like stringi because it makes string handling in R a lot less aggravating but you're just the less general purpose package.

@gagolews

This comment has been minimized.

Show comment
Hide comment
@gagolews

gagolews Jul 25, 2014

Owner

Maybe you're right. So, we'll deprecate %>% in the next version.

Owner

gagolews commented Jul 25, 2014

Maybe you're right. So, we'll deprecate %>% in the next version.

@gagolews gagolews self-assigned this Jul 25, 2014

@gagolews gagolews added this to the stringi-0.3 milestone Jul 25, 2014

@stefanfritsch

This comment has been minimized.

Show comment
Hide comment
@stefanfritsch

stefanfritsch Jul 25, 2014

That's great news, thanks a lot! :)

That's great news, thanks a lot! :)

@bartektartanus

This comment has been minimized.

Show comment
Hide comment
@bartektartanus

bartektartanus Jul 25, 2014

Contributor

There is another solution for this problem. Let's be honest - %>% operator is so simple and universal that many packages might use this, not only our's. If you want to use stringi package and load it AFTER magrittr, load like this:

library("magrittr")
"a"%>%"b"
## Error in "a" %>% "b" : RHS should be a symbol, a call, or a function.

# from R doc for library function:
# if you want to mask as little as possible, use
> library(stringi,pos = "package:base")

Attaching package:stringiThe following object is masked _by_package:magrittr:

    %>%

"a"%>%"b"
## Error in "a" %>% "b" : RHS should be a symbol, a call, or a function.

as you can see, our package did not mask operator from magrittr.
I think this is the best solution for both packages and users :)

Contributor

bartektartanus commented Jul 25, 2014

There is another solution for this problem. Let's be honest - %>% operator is so simple and universal that many packages might use this, not only our's. If you want to use stringi package and load it AFTER magrittr, load like this:

library("magrittr")
"a"%>%"b"
## Error in "a" %>% "b" : RHS should be a symbol, a call, or a function.

# from R doc for library function:
# if you want to mask as little as possible, use
> library(stringi,pos = "package:base")

Attaching package:stringiThe following object is masked _by_package:magrittr:

    %>%

"a"%>%"b"
## Error in "a" %>% "b" : RHS should be a symbol, a call, or a function.

as you can see, our package did not mask operator from magrittr.
I think this is the best solution for both packages and users :)

@stefanfritsch

This comment has been minimized.

Show comment
Hide comment
@stefanfritsch

stefanfritsch Jul 30, 2014

I did an experiment over the last few days with a few of our users and that solution simply does not work for average users. The bugs are too subtle and reordering the search path after they've loaded stringi "the wrong way" is too advanced. There is simply no way I can recommend stringi for our in-house work let alone for our customers if that is the "solution", I'm sorry. :(

And we don't use any other package that implement %>% either. (I couldn't even name one)

I did an experiment over the last few days with a few of our users and that solution simply does not work for average users. The bugs are too subtle and reordering the search path after they've loaded stringi "the wrong way" is too advanced. There is simply no way I can recommend stringi for our in-house work let alone for our customers if that is the "solution", I'm sorry. :(

And we don't use any other package that implement %>% either. (I couldn't even name one)

@gagolews

This comment has been minimized.

Show comment
Hide comment
@gagolews

gagolews Jul 31, 2014

Owner

OK, for your (and others) convenience, we scheduled %***% for removal.

Perhaps we'll use %s>% and alike

Owner

gagolews commented Jul 31, 2014

OK, for your (and others) convenience, we scheduled %***% for removal.

Perhaps we'll use %s>% and alike

@stefanfritsch

This comment has been minimized.

Show comment
Hide comment
@stefanfritsch

stefanfritsch Jul 31, 2014

:)
Thank you very much.

:)
Thank you very much.

gagolews added a commit that referenced this issue Aug 3, 2014

@gagolews gagolews closed this Aug 3, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment