Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Concerns about if 1.0.0 really is user focused. #1001

Closed
mlane3 opened this issue Nov 11, 2022 · 3 comments
Closed

Concerns about if 1.0.0 really is user focused. #1001

mlane3 opened this issue Nov 11, 2022 · 3 comments

Comments

@mlane3
Copy link

mlane3 commented Nov 11, 2022

After reading news in #999 and the reactions on the twitter post, I do not feel that the changes to core purpose of purrr aligns with how the packages is used by everyday non-developers. These are the following reasons why.....

Major Concerns:

"prepend(), rdunif(), rbernoulli(), when(), and list_along() have all been deprecated (#925). It's now clear that they don't align with the core purpose of purrr."

Why are rbernoulii and when being depreciated and not moved to separate package? In particular "when()" does not have a replacement prior to 4.2.2 because there are bugs in gsub that were only recently patched in the last few months. Why don't simple make a wrapper to the proper function until the next major release of base R? We have strong concerns about the development of R packages and whether users have a voice or if everything has become developer focused. It does not feel like the depreciation is gradual at all. When myself and my teammates read the new changes, we truly felt that the developer of the packages either doesn't understand or they simple don't care how non-developers use there open source package.

"*_dfc() and *_dfr() have been superseded in favor of using the appropriate map function along with list_rbind() or list_cbind() (#912)."

When I read this news I truly feel the developer of the packages don't understand how non-developers use there open source package. We have strong objections to this change and concern when combined with other changes it only allow users to purr over a limited number of R data frame types, classes, and most importantly environments.

"lgl(), _int(), _int(), and _dbl() now use the same (strict) coercion methods as vctrs (#904). This means that..."

So you are going to take vctrs, something that is arguably the worst implemented change in all of tidy verse history. And now apply it to all of purr? Your taking something that broke so much code and tutorials 3.6 and 4.0 that your now applying it to purr? When I read this news I truely feel the developer of the packages don't understand how non-developers use there open source package. How is this a gradual depreciation? We have strong objections to this change and concern when combined with other changes it only allow users to purr over a limited number of R data frame types, classes, and most importantly environments.

"map2(), modify2(), and pmap() now use tidyverse recycling rules where vectors of length 1 are recycled to any size but all others must have the same length (#878)."

Is very confusing because it implies that first index, second index are the same length. Why would use use map2 at all then? Why have a second index or second anything if your first is the same? How would anyone know how to use the package? These index changes are an example of why the vctrs and dplyr principles don't make sense. It would make more sense to add a function to make recycling rules explicit. It would make even more sense not to touch the length of indexes at all.

@mlane3
Copy link
Author

mlane3 commented Nov 11, 2022

I am sorry maybe its an issue in the messaging but I truly feel that some of these changes are out of touch with how people like myself and other use R. I know you probably didn't intend for it to be read that way, but at least from how it is initially presented... this is how it feels.

@hadley
Copy link
Member

hadley commented Nov 11, 2022

I can tell from your message that you feel very strongly about this, but it would be more helpful if you could provide specific technical concerns. A few things that I found confusing:

  • I don't understand the connection between when() and gsub()
  • I don't think you understand what superseded means: it means that the function will continue to exist but it will only receive critical bug fixes.
  • I'm not sure what your complaint with vctrs is, but I think being able to do map_chr(1:5, \(x) x / 2) is rather dangerous.
  • We always recycle vectors of length 1 so map2(1, 1:10, `+`) still works. But map(1:2, 1:10, `+`) and map2(1:3, 1:10, `+`) will not.

@hadley hadley closed this as completed Nov 23, 2022
@hadley
Copy link
Member

hadley commented Nov 23, 2022

happy to discuss this further, but I'm closing the issue for now since it's not actionable for me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants