Consider using *labelled* as backend

[thibautjombart]

It seems the package {labelled} is doing something very similar to our tagging system. We should consider using it as a backend. Some considerations:

• check it can actually replace current functionalities
• check if it adds useful functionalities
• check how many deps would be pulled in

[Bisaloo]

I learned today through @noamross that {labelled} is well-integrated with RStudio.

Digging through the code, it looks like it's not an integration specifically for {labelled}, but a generic feature for attr(, "label").

I think this looks quite nice so we should either switch to {labelled}, or for a base approach, replace attr(, "tag") by attr(, "label") in {linelist}.

[Bisaloo]

I've been doing a little bit more digging. The two approaches are actually much more different than what I said in my previous message:

• {labelled} set tags to the specific columns
• {linelist} set tags to the data.frame

There are benefits to both approaches. In particular:

• {labelled}:
  • it is harder to drop the attr() by accident
  • names<-(), rename() work out of the box without the need for a specific method
  • internal code can be greatly simplified in many cases
  • integrates well with RStudio UI
• {linelist}:
  • it is possible to retain tags even after columns are dropped but I don't believe this functionality is exposed to users
  • internal code can be greatly simplified in many cases (e.g., selecting specific tags can be done more easily, without having to loop through columns to extract their label)

Overall, it may be visible from my message that I prefer the attr() by column approach. However, I think it would require a major rewrite of the package and possibly cause some breaking changes, which is much more than what I had in mind when I started looking at this issue.

[Bisaloo]

Another alternative to mention in the README: https://github.com/karoliskoncevicius/annmatrix

[Bisaloo]

Interesting related blog post: https://www.pipinghotdata.com/posts/2022-09-13-the-case-for-variable-labels-in-r/

[Bisaloo]

https://mastodon.social/@olivroy@fosstodon.org/112960647557503220

Labels as column attributes are now / will soon be used in:

• Rstudio auto-completion tooltip
• ggplot2 default axis (Default labels from attributes (option 2) tidyverse/ggplot2#5879)

The switch to datatagr may be a good time to reconsider this and maybe pull the plug @chartgerink

[chartgerink]

Migrating this issue to datatagr to keep track of where it will be most relevant 👍

[chartgerink]

I started looking into this issue with two main questions. 👇

Do we need to introduce a new dependency?

It seems like the main thing to get these labels into place is rather straightforward, even in the labelled package. Specifically, it is as follows:

attr(x, "label") <- "put your label here"

When x is a data.frame, as it is in our case, we need to assign these attributes at the variable level as such:

attr(x$var, "label") <- "put your label here"

Can we introduce this functionality while also remaining backwards compatible with linelist?

In an initial effort to implement this, I realized we could duplicate the information and enable compatibility with linelist. Specifically, we could keep the tagging functionality as is, and add something along these lines to label the variables accordingly (but then vectorized):

for (tag in tags) {
    attr(x[[toString(tag)]], "label") <- names(tags)[tags == toString(tag)]
}

However, this would be a duplication and risks the information diverging. We could write tests to capture all kinds of scenario's, but this risk may still remain. This duplication would allow us to keep the functionality as is already implemented in linelist today, and remain backwards compatible. It would also change the implementation problem from recreating the functionality on a variable level basis (with the rewrites involved) into a information parity problem (ensuring it does not diverge). I am not sure yet which one is more effective.

Next steps

It seems like we can (1) introduce the labels without adding dependencies and (2) stay backwards compatible with linelist. However, we will have to ensure information parity between the tags and the labels, otherwise things can break down quickly. The remaining question is which of the following options we want to go for:

1. Maintain backwards compatibility with linelist and add on the labelling as a secondary feature (with appropriate testing to ensure parity)
2. Revamp the primary tagging feature to focus on variable level labels and make all cascading adjustments needed for this

What are your thoughts on this problem, @Bisaloo?

[Bisaloo]

My recommendation would be to:

• indeed set attr(, "label") directly, without taking labelled as a dependency
• pull the plug and make a breaking change to implement tagging by column, which seems to be a more commonly accepted standard (i.e., option (2) in your next steps section)

[chartgerink]

Very well 😄