SV4 on R?

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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._