Move tbl_cube to another package

[romainfrancois]

This is not really part of the core dplyr experience, so the cube functionality can be moved to another package with its own release cycle, etc ...

[juangomezduaso]

In sight of the advanced state of the rray package and the functionality it already has, I wonder if it wouldn't be much better to let it take care of the use cases where array is the natural data structure to use, and dedicate the efforts to ease the transitio between both "worlds".
I brainstormed the same idea from the other side in this post

[krlmlr]

@juangomezduaso: "this post": did you mean to add a link?

CC @DavisVaughan.

[DavisVaughan]

I still think the idea of a 3D data structure of mixed types could be useful in some fields, so I don't think rray would ever replace the tbl_cube completely. I do agree that it would probably be better suited in another package though

[juangomezduaso]

Oh sorry! Yes,In wanted to link to: r-lib/rray#231 (comment)
tblcube, as it is now, seems to me like a somehow constraining alternative to the use of independent rray arrays. I understand that it was designed to folow the conventions and philosophy of dplyr, and so it was limited to be just a different backend to implement the same functionality (verbs) of dplyr in situations where the exhaustivity of the crossing of clasifications makes it more compact and performant to use arrays rather than the relational usual alternative in dplyr backends.
But I think that in these scenarios broadcasting arrays are a better data model. Specially when there are lots of calculations mixing variables at different levels of aggregation, dplyr requires many joinings that broadcasting arrays just dont need.
Perhaps a new tblcube based on rray arrays would reach agood compromise, but I think that tying the measures in a dataframe style is unnecesarily constraining the posibilities. Arrays can go beyond the sql alternative role and be kind of a a worksheet substitute.
So I see a better path for the tidyverse to take advantage of the two excelent packages it now has, letting each one take care of what it does best and easing the transition between both data models (with ideas lke the one commented in the linked issue)

[lock]

This old issue has been automatically locked. If you believe you have found a related problem, please file a new issue (with reprex) and link to this issue. https://reprex.tidyverse.org/