[Rd] package 'stats' needs import directive for 1.9.0?

[Paul Gilbert]

Prof Brian Ripley wrote:

>On Fri, 27 Feb 2004, Paul Gilbert wrote:
>
>  
>
>>Prof Brian Ripley wrote:
>>
>>    
>>
>>>On Fri, 27 Feb 2004, Swinton, Jonathan wrote:
>>>
>>>From: Prof Brian Ripley <ripley at stats.ox.ac.uk>
>>>Subject: Re: [Rd] package 'stats' needs import directive for 1.9.0?
>>>To: "Heywood, Giles" <Giles.Heywood at CommerzbankIB.com>
>>>Cc: R-devel at stat.math.ethz.ch
>>>      
>>>
>>>>... 
>>>>   
>>>>
>>>>        
>>>>
>>>>>I suggest you don't try: there are already quite a few 1.9.0-specific 
>>>>>versions of packages on CRAN, and 1.8.x will be history in a 
>>>>>couple of 
>>>>>months.
>>>>>
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>I'm not sure I understand the advice here. I have also hit the same problem,
>>>>and it seems reasonable to me to aspire to maintain a single package which
>>>>works on both 1.8.x and 1.9.x. 
>>>>   
>>>>
>>>>        
>>>>
>>>It is not easily possible if namespaces are involved.  We failed to 
>>>anticpate that we would need version-dependent namespaces until rather 
>>>late and then decided not to set up an elaborate solution when most people 
>>>affected had already made separate versions for 1.9.0.
>>> 
>>>
>>>      
>>>
>>I'm confused (not for the first time).  I can see that namespaces are an 
>>additional problem, but I thought the original question was about 
>>defining an S4 generic "start." 
>>    
>>
>
>That's not what the subject line says, and the problem I was addressing is
>that the NAMESPACE file needs to be different in 1.8.1 and 1.9.0-to-be.
>
>  
>
>>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.)

Paul Gilbert

>
>  
>