Drop aliases?

[hadley]

Or move to another package?

I now feel like there's less need for them since I think x %>% .[[1]] or x %>%>(5) are just as expressive. I'm a bit concerned that they're very short names, so they claim a potentially quite expressive part of the language in a commonly used package.

[smbache]

It appears to me that this would be a quite unpopular decision. (At least) some aliases are used quite a bit, AFAIK. Also, I'm not so sure everyone would think that

some_data %>%
  `colnames<-`(...)

is as expressive and clean as

some_data %>%
  set_colnames(...)

There are of course a few aliases that are potentially at risk of claiming useful names, such as add or extract. On the other hand, add does exactly that.

Maybe I'm biased a bit away from seeing the "issue" exceeding the "value" b/c I use

#' @importFrom magrittr %>% add extract

for packages, and

import::from(magrittr, "%>%", add, extract)

in scripts.

[hadley]

Basically I never attach magrittr because I don't want all the extra aliases, and I feel uncomfortable encouraging other people to do so because the risk of conflicts seem high.

Why not move to a separate package? It would cause a little pain in the short run, but would also more delineate the scope of magrittr.

[kristang]

I think a number of those aliases are very useful and increases the readability of code by magnitudes. extract, use_series and inset are especially expressive in my opinion, and the whole point of magrittr and specifically the pipe is increasing readability of ones code, is it not?

[smbache]

@hadley do you ever encourage attachment? ;-)

Just brainstorming, could one have, say,

library(magrittr) 
# access some expressive pipe aliases:
use_alises("inset", "use_series")

and/or maybe

library(magrittr)
define_aliases(add = "+", extract = "[")

But still, I'm a little worried about the breakages this could cause for people.

[hadley]

magrittr2 😉

@kristang I have no idea what use_series and inset mean, and would have to look them up.

[smbache]

@hadley You can set up a Twitter poll to decide what the users want?

[krlmlr]

I fine with 5 %>% "*"(2) instead of 5 %>% multiply_by(2). (Backticks are only accessible via dead key in my layout.) However, I do have existing code that depends on those aliases.

[smbache]

Still not sure what I think about moving the aliases, but here's a Magritte quote that would be suitable for such a package:

"Everything we see hides another thing, we always want to see what is hidden by what we see."
- Rene Magritte

[seasmith]

In many cases, there is actually less typing involved for the actual function vs the alias function ([ vs extract; [[ vs extract2; and the equality comparison operators).

I think it would be more useful to add simplified helper functions. For example, using %T>% to pass a value to save() will produce an object with the name . - literally. Not very useful. However, the work-around would be a helper function like:

save2 <- function(. = ., name, file = stop("'file' must be specified")) {
  assign(name, .)
  call_save <- call("save", ... = name, file = file)
  eval(call_save)
}

# Example
all_letters <- c(letters, LETTERS) %>% sort() %T>% save2("all_letters", "all_letters.RData")
load("all_letters.RData", e <- new.env())
ls(envir = e)
# [1] "all_letters"

In this example, name is assigned the . object, name is then used in call(), and eval() invokes the function.

[ahcyip]

Just bumped into magrittr::set_names when I actually wanted purrr::set_names
This issue was flagged and closed here #158 , but I wanted to point out that the conflict within tidyverse is still around.
The other one is magrittr::extract and tidyr::extract

I do find some of the aliases useful for code readability, so I'd hate to see all of them removed, but it'd be nice if set_names and extract had only one meaning within the tidyverse) :)