[Rd] SV4 on R?

[Frank E Harrell Jr]

Dear Luke,

Thank you very much for the explanation and for the
good work you are doing on this.  It sounds very
valuable.  I do hope that it will not lead to
non-downward-compatible changes in the S language
except in perhaps unusual cases not affecting
many functions.

One other thought: Something short of what you
are developing could be implemented in the meantime,
namely "manual name registration" through a database
on r-project.org through which developers and users
could register function and class names.  Users
developing packages who desire to reuse an
already registered name would be able to search
the database to find potential incompatibilities 
or overrides they would need to warn users of the
package about.  Periodically-run automatic
database queries could compile lists of conflicts
that can be used to warn all users, with a
suggestion that those registering names last should
consider renaming tings. 
I believe that Stata, along with the
many other good decisions they have made, has
a web-driven registration system.  If Stata's
language were decent I would have been using it.

Let me renew a plea I've made before which will
lessen the need for some overrides.  A user-specified
vector of attribute names (e.g., "label", "comment",
"units") that would be carried forward when a vector
or matrix is subsetted would do away with the need for
the few overrides I have in R implementations of my
libraries, for [.* functions.

Best regards,

Frank Harrell


Luke Tierney wrote:
> 
> 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

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