On 01/24/2011 08:37 AM, Kasper Daniel Hansen wrote: > Johann, > > whether S4 is "better" than S3 is a heated subject. No-one (I think) > disputes that S4 is in some sense more flexible (for some suitable > definition of flexible), but it does incur some performance overhead > (how much is debatable) and some would argue that it also makes code > more complicated and harder to debug. > > But take a look at stats4. > > Kasper > > On Mon, Jan 24, 2011 at 11:01 AM, Johann Hibschman <jhibsch...@gmail.com> > wrote: >> "Janko Thyson" <janko.thyson.rst...@googlemail.com> writes: >> >>>> I'm experimenting with a few model-fitting classes of my own. I'm >>>> leaning towards using S4 for my classes, but the R functions I'd want >>>> to override (residuals, predict, etc.) are all S3 methods. >> >>> For example, inside your method for 'residuals()', you will >>> probably just get some data out of a slot of your object and run the S3 >>> function 'residuals(your.slot.data)'. So there's nothing that should make >>> you nervous in that respect, you're not overwriting anything with your >>> method. Setting a generic for an existing function is just a necessary step >>> in order to specify S4 methods for it. >> >> Yes, I understand that it's a necessary step in R, but I'm still puzzled >> as to why it's necessary. (And by "why", I don't mean the technical >> point that 'residuals' is not an S4 generic function; I mean why isn't >> it a S4 generic function already?) >> >> In principle, R could be shipped with all S3 functions replaced by S4 >> functions that default to the S3 implementation. That would be a >> benefit to everyone writing S4 objects. The fact that it's not been >> done seems to imply it would have a cost to people writing S3 objects, >> so I'm trying to understand what that cost is.
As Kasper mentioned the current S4 implementation has costs in terms of performance and usability that I suppose make it unappealing as a 'built-in' feature of R. The current situation, where individual package developers promote a function to an S4 generic, can lead to many issues. Some of these represent bugs in the implementation of S4, e.g., incorrect dispatch with complicated class hierarchies and package dependencies, that are very challenging for the average developer (me, for instance) to fathom. There are also more conceptual issues, e.g., two packages can each create generics that are exported from separate package name spaces, with the usual rules of the R search path determining which generic is discovered. This is very confusing to the user, who has been told that they are using a 'generic'. Documentation is also very confusing, as the generic is documented in several different places. These issues become increasingly important as package hierarchies required for analysis become complicated; the average CRAN package has relatively few dependencies and for many there will be no problem. The class hierarchy and collection of packages for a typical Bioconductor analysis can be quite large and complicated, leading to subtle problems. Martin >> >> Perhaps I'm seeing an implied risk where I really should be seeing a >> loose federation of developers with disparate interests, and the slow >> pace of "global" change that implies. >> >> Thanks, >> Johann >> >> ______________________________________________ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Computational Biology Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109 Location: M1-B861 Telephone: 206 667-2793 ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
