[RsR] covrob --- some OOP-comments

[Valentin Todorov]

Contrary to our assumption, it seems that S3 and S4 classes cannot
live in freedom in one and the same package, which forces me to give
up my initial plans and rather start a new (temporary) package,
"rr4cov" - which will contain all S4 stuff, until it is stable. After
that I'll move it to robustbase and I hope it will not be necessary to
create a separate "robust4base" package. In order not to disturb the
current and potential users of rrcov, I'll not upload the new one to
CRAN, but will put it at the follwoing address  for testing and
comments (please!)

Source tar:
http://www.het2.org/wiki/upload/5/5b/Rr4cov_0.1-1.tar.gz

Windows binary:
http://www.het2.org/wiki/upload/7/76/Rr4cov_0.1-1.zip

I have also changed the naming scheme, trying to make it consistent
with several of the simplest OO-naming conventions - see the updated
diagram at

http://www.het2.org/wiki/upload/d/d6/Rrcov.gif

best regards,
valentin




> There are "some" standards, but not endorsed officially;
> particularly there is no capitalization or "prefix"
> standard.  In a 'function based' OO system like S4, the classes
> are a bit less visible than in a 'class based' system like C++/Java.
>
> Several of the more classical R packages that have been using S4
> use simple all-lowercase-alphabet class names such as 'mle' or
> 'pixmap' but also 'sparseMatrix'.  The one ``rule'' that I think
> "everyone" agrees on is  that the creator function, particularly of
> a ``principal'' class, should have the identical
> name as the class it creates. E.g. mle() returns S4 objects of
> class 'mle', Matrix() returns objects inheriting from class
> "Matrix", etc.  However even this rule is sometimes not
> practical for diverse reasons, typically name clashes with
> already existing functionality in R (in possibly other packages, etc).
> One of the main reasons that IMO it doesn't make sense trying to
> impose such standards is the fact that S (and hence R) has a
> history of more than 20 years, and one has wanted to stay back
> compatible as much as possible when providing new facilities.
>
> If we try to adhere to the only "agreed upon" standard above, our
> class would need to be called  "covrob";  its super class (which
> conceptually also contains the classical non-robustly estimated
> covariance structures) could well be called "cov", even though
> the standard cov() function does not return classed objects.
> Further thinking about this directly leads to Valentin's 2nd
> question:
>
>     ValenT> - What happens with the user of, for example
>     ValenT> covMcd() when it begins to return an S4 class "Mcd"
>     ValenT> instead of the current S3 "mcd".
>
>     ValenT> Of course these that just use print/plot/summary
>     ValenT> will not notice the change, but what about these
>     ValenT> that use the returned object within their programs?
>
> Very good point that has also come to my mind when contemplating
> your proposed inheritance / class hierarchy:
>
> All the user's code / scripts / functions that rely on the
> current structue of, say,  covMcd(),  will stop working
> correctly.
>
>     ValenT> This is actually a general question on compatibility.
>
> Indeed!
>
> One approach that I usually favor is to require new function
> names for getting the new-class results *and*
> keep the old functions returning a back-compatible result; in
> the present case keep covMcd() or covOGK() returning the lists
> (and maybe S3 class) they currently return.
>
> That would be one argument pro only having covrob() return an S4
> class and all the underlying "method functions" return lists
> (possibly with an S3 class) -- just about what Peter and Heinz
> have been proposing.  Additionally one could have newly named
> functions {say 'covMCD'} that call the same underlying "method
> functions" as covrob, e.g. call 'covMcd(..)', and only covMCD
> would return an S4 class "covMCD" which extends (or "inherits
> from") "covrob".
>
> The completely alternative approach would be to declare that all
> current users of 'rrcov' (or 'robustbase') should change their
> scripts and functions whenever they start using the
> new_generation-version of "robustbase" and start using the slots
> (or accessor functions were we provide them) of the new
> S4-classed return values.
> This 2nd ``brutal'' approach (of non-compatible upgrade) is
> possible in situations where not too many users of the current
> package exist, and they basically agree to do the extra work of
> upgrading their R scripts.
> Personally, I'm  *very*  reluctant against compatibility
> breaking -- though I agree it has to happen sometimes in order
> to not hinder progress.
>
> Martin
>