From rossini@u.washington.edu  Tue Mar 19 17:43:38 2002
From: rossini@u.washington.edu (Anthony Rossini)
Date: Tue, 19 Mar 2002 09:43:38 -0800 (PST)
Subject: [Rd] Question re:S4 classes and design; clashing classes?
Message-ID: <Pine.LNX.4.43.0203190943380.28638@hymn08.u.washington.edu>

Thanks to Duncan's recent work on SJava, I've got a (so far) stable
platform to put together the R-Orca interface (dynamic graphics,
including brushing, subseting, etc).  While the first version will be
looking at installation issues and study basic user interfaces for providing a  
few working examples, it will be important for this particular package to look  at how one integrates a "toolkit" at the user-level with other R libraries.

The obvious place (to me, at least initially) to look is at how the S4
classes might be used for this.

However, I'm having a heck of a time wrapping my head around the
proper design for this.

Here is the general issue:

For "normal data objects" with standard data views (i.e. class of
grand tours, etc), I can simply setMethod on the standard data views,
i.e.

setMethod("grandtour","dataframe", ...)  # standard unstructured grand tour
setMethod("grandtour","Surv", ... )      # tour, restricting temporal data,
                                         # handling survival

etc.  I'm fine on this, and have an acceptable sense of what I'd like
to do here.  Note that here, I'm talking about visualizations that
currently exist, not that might be written for such data.  This is in
fact the first step beyond the package I'm currently finishing up.

For the third version (beyond the initial package and beyond the initial methods version of the package), I've got a second class of objects,
i.e. the data views (possibly customized themselves), which I'd like
to think about.  In particular, I'd like to be able to extend/subclass
"grandtour", for example, to regular ("nice") longitudinal and
spatio-temporal data, i.e. classify the methods, not just the data
being acted on by the methods.

I think I'm missing something really obvious here, and I suspect it is
related to using too many object-oriented systems (I'm more used to
Python's, right now, for example; but even with Java, there is a sense
of balance between methods and data within a class).  Thinking about
it more, I guess I'm not clear on the path or approach that S4 classes
use for inheritance and for contractual negotiation.

Here's the example that I'm using as a basis for thinking about design:

I've got a grandtour object which has slots for Data, Colors (a vector
used for subsetting from brushes -- one can color points in orca or
from R, this being the first approach for it), as well as Guidance (at
this point, merely a string, but will be classed for robustness and
extensibility at somepoint).

At the first step, this is for a single sample.  Now, I'd like to
extend this to problems where one variable is fixed (i.e. TIME, in the
longitudinal or time-series problem, or GROUP, in the correlated data
setting).  So we've got, in a sense, the multiple inheritance problem.
I'd like to be able to inherit from both the Orca object as well as
the data library object.

In other OO systems, I'd subclass grandtour, probably using multiple
inheritance, and modify only the methods which change (or to
paraphrase the Java approach, use interfaces for the orca toolkit, and
classes for the data libraries).  For example, I might want to try a
different visualization for survival data, and only want to change the
display in some way (not the brushing/colors or guidance methods).
I'd like to be able to "rerun" numerical analyses on potentially
interesting subsets, or possibly even predict from current fit models,
and have the required objects be part of the orca object.

Orca objects could have associated methods: dumpPipeline, buildPipeline, brush/selectData, getData, setData, addPipe, rmPipe.  In particular, the Data methods will need to use S4 data objects.

Do I simply extend the data classes to add slots for visualization and the requisite parameters and subclass from existing R libraries?  (i.e. add slots for both parameters and dispatched functions). 

Is there a better approach to approaching this problem (which should
be phrased as: "I've got more than one set of initial classes to build from; what might be the preferred approach to extend"?)

I think I'm missing something from reading John's Green book.  If
anyone has pointers to pages/sections I need to read much more
carefully, I'd be grateful to hear them!

(note: I know a number of approaches for how I can implement it, but I
don't have a good enough sense of S4 class design intentions to pick
any of them as being "reasonably faithful" to good S4 design).

best,
-tony


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


[Rd] Question re:S4 classes and design; clashing classes?
Anthony Rossini