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: [EMAIL PROTECTED] Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu ______________________________________________ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel