On Fri, 27 Feb 2004, Paul Gilbert wrote: [...]
> >>This would conflict (and override?) the > >>S3 generic in base, which I don't think is allowed in 1.9.0. Until > >>recently I have been overriding the start function in base (and some > >>others) with my own S3 generic, and have just gone through a rather > >>lengthy exercise to rename these functions and some objects and other > >>methods so that things do work in 1.9.0. (They do also work in 1.8.1.) > >> > >>Will S3 and S4 generics for start co-exist? What happens to all the S3 > >>methods for start if the S4 generic is loaded? Won't this break a lot of > >>code other than mine? > > > >There should be no problem with an S4 generic, as it calls the actual > >existing S3 generic as its default S4 method. It's done for plot(), for > >example. What will not work is having a different S3 generic of the same > >name in a different namespace (including in the residual non-namespace). > > > Ok. Will two S4 generics co-exist? Perhaps the S4 generics should be > defined in base just in case someone else wants to to have an S4 start > method too? (This would apply to a lot of other S3 generics in addition > to start.) Essentially, yes they can coexist and there is no need to predefine S4 generics just in case someone wants to write methods. As I said, cases like plot() and summary() get used in lots of places (although plot() is AFAIR defined in methods). -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UK Fax: +44 1865 272595 ______________________________________________ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
