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

Question

Hi all,

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.

Answer 1

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 2

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 3

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 4

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 5

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.