Hi Tim, well, I am not arguing that there are situation when one needs to rewrite everything from scratch. However it is always worth at least considering inheritance if there is a candidate to inherit from. It saves a lot of work.
Anyway, your examples of S3 class usage are obviously valid in sense that they are indeed S3 methods providing desired functionality. However, I still do not see WHY using attributes with S3 is better than slots and S4 for structures like those inherited from 'array' or similar. S3 gives more freedom in assigning new attributes, but this freedom also means that one has little control over the structure of an object making it, for example, more difficult to use with C/C++ code. Are there any specific benefits in not using S4 and slots (apart from some known performance issues)? Best, Oleg Tim Hesterberg wrote: >> Tim Hesterberg wrote: >>> It depends on what the object is to be used for. >>> >>> If you want users to be able to operate with the object as if it >>> were a normal vector, to do things like mean(x), cos(x), etc. >>> then the list would be very long indeed; for example, there are >>> 225 methods for the S4 'bdVector' class (in S-PLUS), plus additional >>> methods defined for inheriting classes. >> This somehow undermines the whole idea of inheritance. If you do not >> inherit, then you are just implementing a class that mimics another one >>from scratch. However, the question then is not about standard methods >> any more, it's about the methods of the class that you mimic. > > My experience with S4 classes is primarily with classes that had > to be implemented from scratch, there was nothing one could inherit > from - bdFrame and bdVector in library(bigdata), miVariable in > library(missing) (sorry, these are S-PLUS only). > > Actually, for miVariable we considered S3 class + attributes, but > in this case we decided that we did NOT want operations like mean(x) > to work without going through a method specifically for the class. > >> ... example of "Image" class omitted here >> >>> In cases like this you might prefer using an S3 class, using >>> attributes rather than slots for auxiliary information, so that >>> you don't need to write so many methods. >> The reasoning here is not really clear. Could you please explain why is >> this better? > > Three examples. First is "bs": >> library(splines) >> bsx <- bs(1:99, knots = 10 * 2:6) >> showStructure(bsx) > numeric[99,8] S3 class: bs basis > attributes: dimnames > °ree scalar class: integer > &knots numeric[ length 5] class: numeric > &Boundary.knots numeric[ length 2] class: integer > &intercept logical[ length 1] class: logical > > (I plan to add showStructure to library(splus2R) shortly.) > > This is an S3 class, a matrix plus some additional attributes. > Everything that works for a matrix works for this object, > without needing additional classes. > > A second example is "label": >> library(Hmisc) >> age <- c(21,65,43) >> label(age) <- "Age in Years" >> showStructure(age) > numeric[ length 3] S3 class: labelled > &label character[ length 1] class: character >> cos(age) > Age in Years > [1] -0.5477293 -0.5624539 0.5551133 > > Another S3 class, basically any object plus a label attribute. > There are a few methods for this class, otherwise it works > out of the box. > > The third is "lm" - a list with an S3 class. Functions that > operate on lists work fine without extra methods. And you can > add extra components without needing to define a new class > (I've done this in library(resample)). -- Dr Oleg Sklyar * EBI-EMBL, Cambridge CB10 1SD, UK * +44-1223-494466 ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
