Dear R-Developers, The traffic today on s-news where Terry Therneau, I, and others are reporting some of the problems we have had using or converting applications to SV4 reminded me of something Duncan Temple Lang had mentioned to me a year ago that I wanted to follow up on. I recall that Duncan said either that if SV4 were to be implemented in R that it would not be the default behavior, or that through an option the new behavior could be turned off. Would you mind bringing me up to date on this? I sincerely hope that what I thought Duncan said last year still applies. Thank you very much for your consideration. -Frank P.S. If anyone receiving this does not subscribe to s-news and wants to receive background information please let me know. -- Frank E Harrell Jr Prof. of Biostatistics & Statistics Div. of Biostatistics & Epidem. Dept. of Health Evaluation Sciences U. Virginia School of Medicine http://hesweb1.med.virginia.edu/biostat -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
On Thu, 13 Sep 2001, Frank E Harrell Jr wrote:> Dear R-Developers, > > The traffic today on s-news where Terry Therneau, I, and others > are reporting some of the problems we have had using or > converting applications to SV4 reminded me of something > Duncan Temple Lang had mentioned to me a year ago that > I wanted to follow up on. I recall that Duncan said either that if SV4 > were to be implemented in R that it would not be > the default behavior, or that through an option the > new behavior could be turned off. Would you mind > bringing me up to date on this? I sincerely hope > that what I thought Duncan said last year still > applies. Thank you very much for your consideration. -FrankThere are lots of aspects of S4 behaviour. Some R already has (connections, preserving logicals in data frames, for example). I guess you are concerned about classes. There I don't think a decision has been taken. There is a `methods' package in R-devel, written by John Chambers that is not yet finished (or I believe so, as it is being changed quite rapidly and is only partially documented). What is likely is that in R 1.4.0 all objects will have classes, and that functions like identical(), as() and is() will be available. So far this has caused only a few problems, mainly because there are not problems like the "named" class presents in S4. (Bit of background: any vector with names in S4 is of class "named", and that includes lists with names.) Assuming we decide to keep it I don't expect that all objects will have a class is not going to be optional. You will get classes like "numeric" from class(x). I think that's a good move. It does mean that a test for null class should be a test of !is.object(x), probably. I do think you and Terry and others are being too negative. The problems are not with designing new S4 classes to do the job, but porting S3 ones. I believe too few people have tried to re-design to make use of S4 classes for there to be enough evidence. FWIW, MASS and nnet have been using S4 classes for a few years quite sucessfully: we re-designed the classes. We stopped because no one else seemed to be moving, and the basic modelling functions are still confined to S3-style objects. Brian -- Brian D. Ripley, ripley@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272860 (secr) Oxford OX1 3TG, UK Fax: +44 1865 272595 -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
On Thu, Sep 13, 2001 at 01:03:11PM -0400, Frank E Harrell Jr wrote:> Dear R-Developers, > > The traffic today on s-news where Terry Therneau, I, and others > are reporting some of the problems we have had using or > converting applications to SV4 reminded me of something > Duncan Temple Lang had mentioned to me a year ago that > I wanted to follow up on. I recall that Duncan said either that if SV4 > were to be implemented in R that it would not be > the default behavior, or that through an option the > new behavior could be turned off. Would you mind > bringing me up to date on this? I sincerely hope > that what I thought Duncan said last year still > applies. Thank you very much for your consideration. -Frank > > P.S. If anyone receiving this does not subscribe to s-news > and wants to receive background information please let me know.One of the reasons for looking at alternatives to the SV3 style classes is that they are not very compatible with one thing I think we need fairly badly: some form name space management. Name spaces are about controlling which variables in a package are visible outside a package and about preventing variables in one package from unintentionally shadowing ones in another. With name spaces packages will be more robust; separately developed packages can be used together more safely. This is why languages like Tcl and Perl have added name space facilities in recent years. For R, name spaces should also make maintaining the existing R code component of the core system easier and also allow more internals to be migrated from C to R. Name spaces are also needed to support some ideas on byte code compilation that are being explored. Some early ideas on how name spaces might be added to R are available off the developer page, http://developer.r-project.org/. Here is the problem with the SV3 approach. Suppose a package SpecialDates defines a special kind of date class along with a SpecialDate method for as.character. A second class DataTree for managing tree structured data defines a function that plots a tree of generic objects using the as.character representations of the objects. The current SV3 approach to dispatch needs to find a definition for as.character.SpecialDate. With a single dynamic search path as we have now that is no problem. But if we try to use name spaces of any form I can think of to limit the things that are visible inside the DataTree package then we also lose its ability to see methods of the SV3 type that are defined outside the names pace, and this severely limits the usefulness of generic functions. Put another way, when a generic function is called with the SV3 dispatching approach it takes the name of the generic function, which might be defined in one name space, and the name of a class whose methods are defined in a second names pace, glues them together to get the method name, and then needs to look up the method name in the right place. But at the call site it has no way of knowing that that right place might be. The only way around this that I can see is to provide some form of registration mechanism for methods, some means of saying explicitly that this function is a method for that generic function and that class. The SV4 model is one way, though certainly not the only way, to achieve this. By having explicit registration of classes the S4 model also provides for a way of having name space management for class names, which is also useful. luke -- Luke Tierney University of Minnesota Phone: 612-625-7843 School of Statistics Fax: 612-624-8868 313 Ford Hall, 224 Church St. S.E. email: luke@stat.umn.edu Minneapolis, MN 55455 USA WWW: http://www.stat.umn.edu -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._