In EBImage I have a very similar situation (well, with more methods). It would be impossible to use S3 in my case as my data structures are images and I need at least two dimensions (but in fact use 3), thus 2 variables to dispatch on in [, which are defined for multiple configurations like integer,missing; integer,integer or logical,missing. To make things faster in S4, I however did not put data into a separate slot, rather derived the class with contains="array", so effectively giving the class all the functionality of array, and only changing the default behaviour for a couple of methods. Obviously one can access the data low level through the @.Data slot, both in C and R. This was a real performance boost compared to putting data into a separate slot, otherwise even working with many images and large sets I have not really noticed any performance issues that would be connected with the speed of method dispatch (although I would not argue that there are none).
Regards, Oleg Dr Oleg Sklyar | EBI-EMBL, Cambridge CB10 1SD, UK | +44-1223-494466 John Chambers wrote: > Prof Brian Ripley wrote: >> On Mon, 7 Jan 2008, Robin Hankin wrote: >> >> >>> I am writing a package and need to decide whether to use S3 or S4. >>> >>> I have a single class, "multipol"; this needs methods for "[" and "[<-" >>> and I also need a print (or show) method and methods for arithmetic +- >>> */^. >>> >>> In S4, an object of class "multipol" has one slot that holds an array. >>> >>> Objects of class "multipol" require specific arithmetic operations; >>> a,b being >>> multipols means that a+b and a*b are defined in peculiar ways >>> that make sense in the context of the package. I can also add and >>> multiply >>> by scalars (vectors of length one). >>> > One thing you cannot do in S3 is to have methods that depend on anything > but the first argument. Do you want something sensible for 1 + a when > a is a "multipol"? The default call to the primitive version may or may > not give you what you want. >>> My impression is that S3 is perfectly adequate for this task, although >>> I've not yet finalized the coding. >>> >>> S4 seems to be "overkill" for such a simple system. >>> >>> Can anyone give me some motivation for persisting with S4? >>> >>> Or indeed reassure me that S3 is a good design decision? >>> >> Does performance matter?: S4 dispatch is many times slower than S3 >> dispatch for such functions. (It is several times slower in general, but >> the difference is particularly marked for primitives.) >> > Well, the question is whether performance of _method dispatch_ matters, > which it tends not to in many cases. And it would be good to have some > data to clarify "many times slower". Generally, looking up inherited > methods is likely to take a while, but only the first time does R code > need to work out the inheritance. On repeated calls with the same > signature, dispatch should be basically a lookup in an environment. > > [[alternative HTML version deleted]] > > ______________________________________________ > 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
