Skip to content

2 setGeneric's, same name, different method signatures

6 messages · Greg Minshall, William Dunlap, Hadley Wickham +2 more

Original
Greg Minshall
# 
William,
sorry, i meant, in something like C++, if i have a class Foo and you
have a class Bar, then i can invent whatever method names/signatures i
want, independent of whatever method names/signatures *you* want.  *i*
just need to make sure i don't introduce incompatible methods with the
same name/signature *within* Foo.


cheers, Greg
William Dunlap
# 
I thought you were thinking of the R class system (the S3 and S4 ones
anyway) as if it were C++'s.  It is quite different.

Bill Dunlap
Spotfire, TIBCO Software
wdunlap tibco.com
Hadley Wickham
# 
This is unfortunately reinforced by the "(Not So) Short Introduction
to S4 Object Oriented Programming in R" - I wouldn't recommend that
document to learn about S4.

The most important thing to get about OO in R is that methods belong
to generic functions, not like classes, as in most other programming
languages.  If you don't get that, you are really going to struggle
with S3 and S4 and you will wonder what on earth the designers of R
were thinking when they created them.

Hadley
On Fri, Feb 15, 2013 at 3:42 PM, William Dunlap <wdunlap at tibco.com> wrote:

  
    

      
      
    

  


  


      

    

    
4 days later

    

      
      

        


  

        

      Romain Fenouil
    

    

      
      #
    

  


  

      
Dear members,
please excuse me for eventual mistake in posting my first message on this
list.

I am actually glad to read these very interesting questions and answers
because I have been facing a related situation for the last 2 days. I am
writing a R package that is using some of the interesting functions offered
by Dr. Morgan's 'ShortRead' library.

I have a C++/Java background and only used R as a scripting language until
now. 
I am now writing my first class with R and everything seems fine until I
tried to define a function (accessor) named 'chromosome' for it.
Indeed this function name is already used in ShortRead library as an
accessor to the corresponding slot.

My others accessors are usually defined like this :

# Getter
setGeneric(name="pairedEnds",	def=function(object, ...)
{standardGeneric("pairedEnds")});
setMethod(	f="pairedEnds",
		signature="myClass", 
		definition=function(object, ...) {return(slot(object, "pairedEnds"))});

# Setter
setGeneric(name="pairedEnds<-",	def=function(object, value)
{standardGeneric("pairedEnds<-")});
setReplaceMethod(	f="pairedEnds",
		signature="AlignedData", 
		definition=function(object, value) {object at pairedEnds<-value;
validObject(object); return(object);});

However, I realized that when I tried to do the same with the 'chromosome'
function, calling setGeneric overrides the previous 'definition' (the
'ShortRead' one) and if I understand correctly, masked it. The consequence
is that I cannot use chromosome anymore on a 'ShortRead' object
('alignedRead').

I think I understood that we can only call setGeneric once per function
name. By the way, if I ommit my setGeneric and only use the setMethod in my
package, it seems to work correctly, probably basing it on the setGeneric
call from the ShortRead library.

My questions are :

1. Is my last statement correct ?

2. How to define a function with the same name as one previously existing in
another package ? How to avoid conflicts in case we load these two packages
at the same time ?

3. In order to avoid several calls to setGeneric, I have been thinking about
a conditional use of setGeneric 'if(!is.generic(myFunc)) setGeneric(myFunc)'
but it seems tricky and I have never seen such use, I guess this would be
problematic...

4. Is this phenomenon happening because I'm doing this in the global
environment (Testing) ? Would it be transparent when in the package
Namespace ?


This method dispatching is very disappointing to me... I believe that these
questions come from my general misunderstanding of how R OOP is designed and
I would be glad to find a reference document for S4.

Thank you very much for your help.

Romain Fenouil.



--
View this message in context: http://r.789695.n4.nabble.com/2-setGeneric-s-same-name-different-method-signatures-tp4658570p4659139.html
Sent from the R help mailing list archive at Nabble.com.

  
  


  


      

    

    

      
      

        


  

        

      Martin Morgan
    

    

      
      #
    

  


  

      
On 02/20/2013 02:19 AM, Romain Fenouil wrote:

            

      
      
      
    

        
actually, the original generic and its methods are still available with

   ShortRead::chromosome

            

      
      
      
    

        
maybe; you should have in your DESCRIPTION file

   Imports: ShortRead

and in your NAMESPACE file

   importFrom(ShortRead, chromosome)

            

      
      
      
    

        
inside your package, you're free to do what you like. If you don't want to 
re-use the ShortRead::chromosome generic, then don't importFrom(ShortRead, 
chromosome)

            

      
      
      
    

        
this used to be an idiom when there was no NAMESPACE, but inside your package 
you know what generics are defined (you've imported them explicitly) so no need 
to test whether they exist or not.

            

      
      
      
    

        
Yes to some extent there are fewer conflicts -- inside your package -- when 
using a NAMESPACE.

            

      
      
      
    

        
I would guess that what you want to do is reuse the ShortRead generic, not 
create a new one, and add your method to it

DESCRIPTION:
   Imports: ShortRead

NAMESPACE:

   importFrom(ShortRead, chromosome)
   exportMethods(chromosome)

R/somewhere.R

   setMethod(chromosome, "MyClass", function(object, ...) {
       ## implementation
   })

Hope that helps, and good luck with your package.

Martin

            

      
      
      
    

        

      
      
    

        

  
    

      
      
    

  


  


      

    

    
1 day later

    

      
      

        


  

        

      Romain Fenouil
    

    

      
      #
    

  


  

      
Dear Martin Morgan,

thank you very much for your answer that made it clear to me.
Since my package is linked to yours by essence, there is no reason to
redefine the existing setGeneric functions.

As a summary, if someone is importing functions from another package, he is
supposed to know they already exist and shouldn't redefine their generic
template. This can sound stupid like that but wasn't clear to me before
putting everything in a package.
Moreover this situation is not an issue while loading another package that
potentially has functions with same names thanks to the Namespaces
implicitly encapsulating the packages.

Thank you again and I hope the package will be of interest for the community
:)

Romain.



--
View this message in context: http://r.789695.n4.nabble.com/2-setGeneric-s-same-name-different-method-signatures-tp4658570p4659349.html
Sent from the R help mailing list archive at Nabble.com.