hrbrmstr / freebase

👃🏽A 'usethis'-like Package for Base R Pseudo-equivalents of 'tidyverse' Code

freebase

A ‘usethis’-esque Package for Base R Versions of ‘tidyverse’ Code

Description

The ‘tidyverse’ is awesome, but can take a bit to compile on systems where there are no pre-built binary packages. Methods are provided which use the facilities of the ‘usethis’ package to snap-in base versions of useful ‘tidyverse’ functions that are mostly equivalent (some are more complete than others). The base R counterpart functions will likely be slower than the ‘tidyverse’ equivalents but using them will decrease ‘Imports’ dependencies.

Use deliberately and with caution.

NOTE

This package shares core concepts with noplyr (and the author of noplyr is a contributor to freebase). For valid, needed reasons, noplyr uses rlang which introduces a compilation dependency/requirement which freebase is trying to avoid. The goal of freebase is 100% base R implementation of core/most frequently used tidyverse components primarily for use by package authors who prefer tidyverse idioms and would like to use them in package development but do not want to introduce compilation and/or third-party dependencies.

As noted just above, freebase should be used deliberately and with caution.

What’s Inside The Tin

The following functions are implemented:

• use_detect: Use base R versions of purrr detect functions (these support ~{} formula functions)
• use_infix_helpers: Use infix-helpers
• use_isers: Use “is_” tester functions
• use_keepers: Use base R versions of purrr keep functions (these support ~{} formula functions)
• use_mappers: Use base R versions of purrr map functions (these support ~{} formula functions) along with set_names()
• use_safely: Use base R versions of purrr safely functions
• use_tidylite(): Use base R versions of core tidyr functions
• use_walkers: Use base R versions of purrr walk functions (these support ~{} formula functions)

Installation

devtools::install_git("git://gitlab.com/hrbrmstr/freebase")

Usage

library(freebase)

# current version
packageVersion("freebase")

## [1] '0.2.0'

freebase's Issues

Type save mappers should wrap vapply and not lapply

The type save mappers should probably wrap around vapply() instead of lapply() with coercion.

Something like: map_chr <- function(.x, .f, ...) vapply(.x, .f., character(1), ...) etc...

I am not 100% sure how purrr::map_chr() behaves different than vapply(). I am currently a bit more busy than I thought, but if the issue stays open long enough, i'll look into them myself eventually.

inst versions are saved without roxygen2 comments

when invoking use* the script that is copied to R doesnt contain comments that fit with roxygen2. i think the script in inst should have comments that are roxygen2 ready.

Function names

This package is a great idea, especially for those of us with strong tidyverse tendencies who are cognizant of heavy ‘Imports’ dependencies, but not necessarily well-equipped to replicate that functionality ourselves. A couple musings about function names...

1. Incorporating tidyverse package name: As the number of functions and tidyverse packages supported (presumably) grows, I wonder if it would be useful to incorporate the package name in the function name. Something like, use_purrr_detects, use_purrr_walkers, use_tidyr_tidiers. Doing so would group functions from the same package together, and provide pointers in cases where one knows they need base versions of purrr functions, but not exactly how the family of functions is labeled in freebase.

2. Mapping to tidyverse function names: Most of the generated functions map 1:1 to their tidyverse sibling, but there are a few exceptions. I think it would be good to be consistent about that. Are there downsides/issues with the 1:1 mapping? If not, making them all that way seems like the best approach. If there are issues I'm not thinking of, would it make sense to adopt a common prefix (perhaps something like freebase_ or base_ or fb_)?

dplyr template?

Hi Bob, any thoughts on having basey equivalents of the dplyr core verbs? I'd be happy to put in a PR when I have time.

use for loop in walk instead of lapply/mapply for better perfomance

The whole idea behind walk is that you are not creating the results object. Because of this walk is more efficient than map/lapply in some cases. If you now use lapply/mapply internally to implement walk you are loosing this advantage. This is one of the cases where a for loop is a better choice than lapply/map.

See also original implementation of purrr::walk and purrr::pwalk

Use a subset of available functions

I'm not sure how feasible or useful this would be, but what do folks think about allowing users to select a subset of the functions in a given template? For example, what if I only need map() but none of its siblings? I assume I would run freebase::use_mappers() and manually delete any functions I didn't need. However, it would be nice to be able to pass the names of the functions I want, and get only those functions in the resultant file. Thoughts?

{tbltools}

I'm not sure if this is useful, but I thought I'd point out that my {tbltools} package has recently turned into a {dplyr}-lite type of package–similar to {noplyr} only without the {rlang} dependency and a {dplyr_verb}_data naming convention.

noplyr:

> library(magrittr)
> mtcars %>%
+   noplyr::filter(mpg > 11) %>%
+   noplyr::group_by(cyl) %>%
+   noplyr::mutate(n = length(gear)) %>%
+   noplyr::summarize(
+     n = unique(n),
+     mpg = mean(mpg)
+   ) %>%
+   noplyr::arrange(mpg) %>%
+   noplyr::select(cyl, mpg, n)
  cyl      mpg  n
1   4 26.66364 11
2   6 19.74286  7
3   8 15.88333 12

tbltools:

> library(magrittr)
> mtcars %>%
+   tbltools::filter_data(mpg > 11) %>%
+   tbltools::group_data(cyl) %>%
+   tbltools::mutate_data(n = length(gear)) %>%
+   tbltools::summarise_data(
+     n = unique(n),
+     mpg = mean(mpg)
+   ) %>%
+   tbltools::arrange_data(mpg) %>%
+   tbltools::select_data(cyl, mpg, n)
  cyl      mpg  n
1   4 26.66364 11
2   6 19.74286  7
3   8 15.88333 12

Call for "is_"-ers

This could be an epic collection of is_ base R functions. It is very lightly populated now.

I'll poke a bit through CRAN contrib pkgs util source files but def add useful ones of your own.

Make sure to add yourself to the DESCRIPTION if you do add functions

Call for infix operators

This could be an epic collection of base R, pipe-ready infix functions. It is very lightly populated now.

I'll poke a bit through CRAN contrib pkgs util source files but def add useful ones of your own.

Make sure to add yourself to the DESCRIPTION if you do add functions

add tests subdir in inst that copies along with script to tests/testthat

Create a sibling subdir in inst that has tests that get copied into tests/testthat when invoking a use_*. That way freebase isnt fudging up ppls covr stats ;). And the tests can be prevalidated centrally via freebase.