[RsR] covrob --- some OOP-comments

[Valentin Todorov]

>> - using of accessor methods. ...

> This /is/ possible:
> *define a class vectororNULL (as in the "Green Book")
> *declare slot 'md' (or perhaps better 'distance') to be of class
> vectororNULL
>  in the setClass-command for 'covstruct'
> *write an accessor function 'distance' (i.e. a method under a corresp.
> S4-generic)
>  which in the first place checks if the 'distance' is NULL and if so 
> writes
>  the values into the parent frame--- something like
>  eval.parent(substitute( object using distance <- distanceValues ))

Yes, everything is in the last line, but I still do not know which object 
will be modified.
In C++ and friends I would define
    dist=null;
in the constructor and then write a get-accessor like this

vector getDistance(){
    if(dist==null)
        dist = computeDIstance();
    return dist;
}

> [1] Just a question of understanding:
>
> Are the methods displayed in Valentin's diagram (like show(),...)
> meant to follow the S4 paradigm, i.e. dispatched according to a
> generic, or are they meant to be functional slots (like in classical
> OOP, e.g. C++)?

I had S4 classes in mind, but it is not that easy to express this in UML:
particularly, the classes Cov, Mcd, Ogk and Mest are S4 classes returned by
the functions cov, covMcd, covOgk and covMest respectively. Most of their
methods - show/plot/summary - are implemented for Cov or the abstract CovR
and can be applied polymorphic on the subclasses.

> [2] more general:
>
> In the "pure" OOP setup as in the Valentin's display,
...

this needs further thinking and discussing...

> The same of course could be done in case of other control structures
> like for the psi functions.

have a look at my implementation of the psi-functions used for the 
constrained
M-estimates in covMest() in the new version of rrcov that I uploaded 
yesterday
(still stays in Incoming, I'll send it you offline).

> On the other hand, we should keep in mind that all these dispatching
> operations will cost some computation time --- so we should
> thoroughly test whether this gain in generality is worth this extra
> effort.

very important. A straightforward, !OOP implementation can be more than
twice faster than S4 implementation. I'll provide some more computational
evidence.


> [OT] : Valentin, what do you use as tool to draw your diagram?
> We have been using some different tool for our S4 packages, but ours
> did not yield half as good results as yours ; ( to be discussed offline 
> ;-)

this particular diagram was done with ArgoUML, but I am still not satisfied.
Before I was using Objecteering, but they have a complicated licensing 
model.
The best that I have used for a long time was Rational Rose: comercial and
extremely expensive, later I used TogetherJ. I do not know what happened,
I am afraid Borland bought them. More on this topic - offline.

best regards,
Valentin