[Rd] Reorganization of packages in the R distribution

[Luke Tierney]

On Fri, 12 Dec 2003, Paul Gilbert wrote:

> If  I understand this change correctly, I think is wrong for R-core to 
> think it is a small change. It has much more serious consequences for me 
> than any changes introduced  R 1.0. It definitely should not be 
> introduced at a dot level release unless there is a fairly simple 
> mechanism to deal with the implications. It breaks  6 of my 9 packages 
> on CRAN at a fairly fundamental level,  2 more at a less serious level,  
> and some packages I have not yet release.
> 
> Perhaps my programming technique is not correct. I always considered 
> this trick to be a work-around for a short coming in R/S.   The issue is 
> that the correct way to do this needs to be implemented before the trick 
> that allows a work-around is eliminated.
> 
> Paul Gilbert
> 
> Prof Brian Ripley wrote:
> 
> >On Fri, 12 Dec 2003, Paul Gilbert wrote:
> >
> >  
> >
> >>Prof Brian Ripley wrote:
> >>
> >>    
> >>
> >>>There are a small number of CRAN packages that attempt to modify system
> >>>functions and so will need updating.  (Known examples are in dse:tframe,
> >>>gregmisc and mclust and some testing code elsewhere.)
> >>>
> >>>      
> >>>
> >>Brian
> >>
> >>What do you mean by "updating?"  In tframe I modify a few functions like
> >>
> >>     start <- function (x, ...) if (is.Ttframed(x)) start(tframe(x), 
> >>...) else UseMethod("start")
> >>
> >>If that can no longer be done then this is a serious fundamental change 
> >>that breaks all my code. I hope that is not what you mean. I'm just 
> >>going away for a week, but will follow up when I return.
> >>    
> >>
> >
> >It's always been incorrect code, and it no longer works.  You should not
> >be masking system generics, as the namespace registration mechanism does
> >not work on your version.
> >
> >  
> >

There are a number of options, depending on what you are trying to do.
If you want to make a definition of how the function `start' should
handle a TtFramed object in a way that should be visible to functions
defined in other packages that use the function start from the R core
packages (formarly base, not stats), then you can do that one of two
ways. The first is the disciplined and supported way: use the fact
that `start` is a generic and define a method for it, as was already
suggested.  That is the point of defining `start' as a generics.  The
undisciplined way it to change the definition in the stats package.
This can be done.  It is hard to do, and that is deliberate.

If your intent is to define a function of your own for use in your
packages that does something you want in one particular case but
otherwise defers to the function `start' in base then you can do that
too.  If this is what you want then things would be clearer if you
used a different name, like

pgStart <- function (x, ...) {
    if (is.Ttframed(x)) start(tframe(x), ...)
    else start(x, ...)
}

If for some reason you must use the smae name, even though that may
not be doing what you think it is doing, then you can explicitly defer
to the version in stats with

start <- function (x, ...) {
    if (is.Ttframed(x)) stats::start(tframe(x), ...)
    else stats::start(x, ...)
}

So we have infact implemented several nice pieces of rope for your use ...

Best,

luke


-- 
Luke Tierney
University of Iowa                  Phone:             319-335-3386
Department of Statistics and        Fax:               319-335-3017
   Actuarial Science
241 Schaeffer Hall                  email:      luke at stat.uiowa.edu
Iowa City, IA 52242                 WWW:  http://www.stat.uiowa.edu