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

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 doing everything the object-oriented way, using S4 methods. My experience on the other hand is that S4 implementations often perform worse and cause a lot more headache when trying to get the code do what you want it to do.

I definitely agree that in some cases, you have to be able to construct complex objects or append existing objects in a controlled manner. But most of the time, S4 implementations can easily be done using classic lists as well, without all the hassle like defining standardGeneric, methods, constructors, initializers and the likes.

When do you consider writing S4 implementations for R?

EDIT : For clarity, I do appreciate the answers and the discussion about OO in general in R. OOP can be done in numerous ways in R, but my question is really aimed at the added value of using S4 methods specifically.

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.

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.

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!

I learnt S4 in order to extend the Spatial (sp) classes for animal track data. It was the best choice (most consistent, general and closely matching to many GIS definitions) from the available options to avoid writing everything required from scratch. I don't find S4 as onerous as many people say, but I'm now used to exploring the underlying structure of objects like this. The performance is good too, I think it can be done well, though when done poorly there are performance traps.

If spatial data is of interest to you, spatstat is a good example of how to do a lot of similar things to sp in S3, though (as with seemingly everything spatial . . .) there's hardly ever clean analogies between data structures in different softwares.

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...)

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().

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