When does it pay off to use S4 methods in R programming

Question

I program regularly in R in a professional context, and I write packages for clients or co-workers as well. Some of the programmers here have a Java background and insist on

Answer 1

Great question! and I hope it generates some thoughtful discussion...

I've never used it, nor do I intend to for the following reasons:

1. Performance
2. I don't have the patience to completely understand S4 and it's relationship to S3.
3. Syntactic suguar: I'd rather have object.method() than method(object).

I like suguar, what can I say!

Answer 2

Once upon a time, Roxygen2 didn't like S4 methods. As of 2017 (at least), they work together.

I've had the misfortune of creating some functions that needed methods to work with both S3 and S4 classes. It has been incredibly painful to keep this code working over the years as R-core has multiple times changed details on how these systems interact and how Namespaces work and how Rcmd check works.

If you don't like Google's style guide, then consider the comments of these well-known R package developers from this thread on R-help

Frank Harrell "If you love computer science more than you value your own time, use S4."

Terry Therneau wrote: For 90 percent of what I do I strongly prefer the loose (S3) rather than the rigid (S4) classes....My summary of S4 vs S3

S4 has a large increment in: 1. nuisance to write 2. difficulty to debug 3. ability to write very obscure code 4. design

S4 Gains: 5. ability to direct automatic conversions 6. validate the contents of a class object

Answer 3

Don't forget there's also R.oo (on CRAN) which provides a third way of doing OO in R. In my mind this provides an OO system that might be more familiar to programmers migrating from other systems - in particular instead of having generic functions (so that print(foo) then has to dispatch on the class of foo) the methods are tied to the object, so you'd do foo$print() - just as in python or C++ you'd do foo.print().

Answer 4

S4 classes play a strong part in spatial statistics (sensu package sp), where converting from one type of data to the other seems seamless. The pitfall of this is debugging, which has been, in my experience, tedious at best. So far, I have managed with S3 but may consider using S4 in the future.

With time, as things get played around a lot, I believe they will play a strong role in at least core features of various fields of R (may that be spatial analysis, econometrics, environmetrics...)

Answer 5

My experience is in line with yours, so I use S3 exclusively.

To clarify: S4 has some slick features (e.g. dispatch on multiple arguments and slot type-checking), but I have not encountered a situation where the features outweighed the costs. Examples of the costs include: any slot change requires a full object copy and (potentially worse) the on-going changes to S4 Methods.

In short, I like the idea behind S4 but I would wait for it to mature before using it in my own code.

Answer 6

I'm assuming this doesn't directly apply to you, but if you're developing packages for Bioconductor there's an incentive to use S4 as they actively encourage it's use and have for the better part of a decade now - so all of the core packages make heavy use of S4.

I find all of the extra overhead to be a pain - the setGeneric, setMethod, dealing with NAMESPACE, etc. That being said, I find that the structure that it imposes, potential for extensibility and other such things can be worth it. As with everything, there are tradeoffs involved. I think it can be a lot cleaner - I dislike how S3 methods are simply disguised by naming convention (foo.class). All that being said, I tend to avoid using S4 heavily in my own code unless I'm being told to do so.