Skip to content

package 'stats' needs import directive for 1.9.0?

7 messages · Swinton, Jonathan, Thomas Lumley, Paul Gilbert +1 more

Original
Swinton, Jonathan
# 
...
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.
I think that explicit Genericisation (?) has virtues from the point of view
of code legibility.
...
My solution was to only do a require(stats)  if running > 1.9.
Brian Ripley
#
On Fri, 27 Feb 2004, Swinton, Jonathan wrote:

            

      
      
      
    

        
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.

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Thomas Lumley
    

    

      
      #
    

  


  

      
On Fri, 27 Feb 2004, Swinton, Jonathan wrote:

            

      
      
      
    

        
It's reasonable to aspire to it, just like maintaining a package that
works under S-PLUS and R is reasonable to aspire to.  I think the
recommendation is that it's not worth the effort, given the short period
of time it will be useful.

	-thomas

  
  


  


      

    

    

      
      

        


  

        

      Paul Gilbert
    

    

      
      #
    

  


  

      
Prof Brian Ripley wrote:

        

            

      
      
      
    

        
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." 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?

Paul Gilbert

  
  


  


      

    

    

      
      

        


  

        

      Brian Ripley
    

    

      
      #
    

  


  

      
On Fri, 27 Feb 2004, Paul Gilbert wrote:

        

            

      
      
      
    

        
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.

            

      
      
      
    

        
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).

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Paul Gilbert
    

    

      
      #
    

  


  

      
Prof Brian Ripley wrote:

        

            

      
      
      
    

        
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

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Brian Ripley
    

    

      
      #
    

  


  

      
On Fri, 27 Feb 2004, Paul Gilbert wrote:

        
[...]

            

      
      
      
    

        
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).