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

Motivation for S7 versus S3 or S4 #513

Open
tripartio opened this issue Dec 16, 2024 · 4 comments
Open

Motivation for S7 versus S3 or S4 #513

tripartio opened this issue Dec 16, 2024 · 4 comments

Comments

@tripartio
Copy link

My issue is related to the closed issue #92, but it also aligns closely with issue #233 because it concerns the differences between S3, S4, R6, and S7.

As a relatively new package developer, I’ve been exploring whether to use S7 in my early-stage packages (ale and autogam) instead of sticking with S3. However, the current documentation hasn’t been very helpful in guiding this decision.

The Motivations for S7 vignette appears intended to address this, but its focus seems to be on answering, “Why use S7 instead of R6?” rather than its stated goal of comparing S7 with S3 and S4. Let me clarify my perspective and needs:

I use S3 primarily because:

  • I need simple print() and plot() methods for my package objects, along with a few custom methods.
  • I don’t need inheritance or a class hierarchy.

For these reasons, S3 has been sufficient. I’ve never seriously considered R6 because its key advantages—such as a well-behaved class hierarchy or its similarity to Python/Java object-oriented systems—don’t apply to my current use cases. I’ve also never used Bioconductor packages, so S4 has remained outside my workflow.

Now, I’m intrigued by S7, which is promoted as the future of S3 and S4. However, for someone like me, who doesn’t need class hierarchies and wants to minimize dependencies, the benefits of transitioning to S7 are unclear. Why should I adopt S7 when S3 meets my needs so effectively?

Could the team provide clearer guidance on these points:

  1. Why should someone using S3 consider switching to S7?
  2. Conversely, in what situations does it make sense to stick with S3 instead of adopting S7?

I suggest these considerations be included in an updated version of the Motivations for S7 vignette, to better address users like me who are weighing S3 versus S7, rather than R6.

@mmaechler
Copy link
Collaborator

mmaechler commented Dec 19, 2024

I think you are right that we've not addressed this in our current "Motivation vignette"; further, I'm just one of the co-authors here. I'm maintaining almost two dozen CRAN packages and also have been teaching to use R and consulting/helping academic/researcher colleagues. In your case, I would stay with S3. It is so simple and well established in R (and S, S+ before that) and used in many fundamental packages, not only "base"/"R core" ones.

Currently, I don't think we know of existing packages which have already been ported from S3 to S7, and I am pretty convinced that such porting should start soonish, for cases where internal consistency is improved and extensions and maintenance of the code base becomes easier both for the maintainers and the users.
Also, I am hoping that we/someone will provide R tools (in R packages) to partially automate such porting, and I also expect more functionality inside the S7 package for exploring and consistency checking of S7 generics, methods and classes. And with usage (of maintainers and users), I'd expect that S7-based package development and use would become much more mainstream and will be seen as very natural and "R - like" (much more than S4 or R6) by the wider R user community. Hence it might be that many (including you) in that moment may be inclined to move from S3 to S7 not only for new packages but also port some of their existing ones.
In spite of that and if you're confident, that print(), plot() {and maybe summary() .. that's the three I tell "everyone" they should provide} are the only methods you'd use and class hierarchy / inheritance / "navigation" is neither needed nor natural, I'd stay with S3 for now.

@tripartio
Copy link
Author

@mmaechler Thanks; you've helped me confirm that S3 is all I need for now in my basic case.

I like to try to reduce things to their simplest elements. In such an updated motivation document, I'd like to see something like:

"Why stick with S3"?

  • If you only need basic methods like print(), plot(), summary(), etc.
  • You don't need class hierarchies or inheritance.
  • You don't need to define new generic methods. [I'm not sure about this last one but I gather that S7 provides cleaner generics than S3.]

I don't know enough about S4 or R6 to suggest a list so simple but from my reading of the S7 website, it seems to me that for any reason that someone might prefer S4 or S6 over S3, S7 could resolve the issue better. If so, the motivation document should explicitly summarize the reasons. I suppose the current version already does this for advanced S3 usage plus S4 usage but I'd like to see an R6 section added.

By the way, could you please add the "documentation" tag to this issue? I think that's its category.

@hadley
Copy link
Member

hadley commented Dec 19, 2024

@tripartio IMO the main reasons to stick with S3 is that you've already written the code. For new stuff, particularly if you haven't written much OOP R code before, S7 is going to be better, not least because it's better documented and gives you better error messages.

@tripartio
Copy link
Author

@hadley Could you please expand on the claims of "better documented and gives you better error messages"?

I'm coming at it from the perspective of effort versus benefit trade-off. I'm coming at it from the perspective of S3 being very simple and S7 needing a bit more effort.

Perhaps after the holiday period I'll play around with an MRE of an S3 class versus an S7 class with just print and plot methods. Then that could demonstrate if my sense of "not worth the extra effort" are unfounded. So, I'll get back to this.

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

3 participants