2 setGeneric's, same name, different method signatures

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

2 setGeneric's, same name, different method signatures

Greg Minshall
hi.  below is a small test case (hopefully minimal, though i'm still a
bit confused about initializers).

i would have guessed (and maybe i still would have been right) that one
could re-use the name of a generic function for functions with different
numbers of arguments.  in the case below, class A's bB() queries the
status of a single A object, so bB(A) (where here "A" is an instance of
class A, just for "clarity") returns a value.  class B's bB() compares
values in two B objects, and returns the minimum, so bB(B1, B2) are its
methods.

after loading the file, i see the method for A's bB has disappeared (as
measured by showMethods("bB"), as well as trying bB(A).  if i have R
re-parse the setGeneric/setMethod  A's bB(), then B's bB() disappears.

somehow my code, or my model of how things work, is wrong.  any ideas
what am i missing?

cheers, Greg Minshall
----
setClass("A",
         representation(
           x="numeric"));

setMethod(
  f="initialize",
  signature="A",
  definition=function(.Object) {
    .Object@x <- 23;
    return(.Object)
  });

setGeneric("bB", function(me) standardGeneric("bB"));
setMethod(
  "bB",
  signature("A"),
  definition=function(me) {
    return (new("B", me@x))});

setClass("B", representation(
  bx="numeric"));

setMethod(
  "initialize",
  signature("B"),
  definition=function(.Object, x) {
    .Object@bx <- x;
    return(.Object);
  });

setGeneric("bB", function(b1, b2) standardGeneric("bB"));
setMethod(
  "bB",
  signature("B", "B"),
  definition=function(b1, b2) {
    return(new("B", min(b1@bx, b2@bx)))});

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Reply | Threaded
Open this post in threaded view
|

Re: 2 setGeneric's, same name, different method signatures

Greg Minshall
i'm answering my own question:

1.  setGeneric's override (wipe out, really) previous ones.  (this is
pointed out in section 5.3 of "A (Not So) Short Introduction to S4
Object Oriented Programming in R" by Christophe Genolini.)

2.  the *names* of the formals are important.

3.  one can specify a method that takes a subset of the formals declared
in the setGeneric.

so, in my example, changing "me" to "b1" in A's bB(), allows A to use
B's setGeneric().

for completeness, below is my code that works (or, seems to!).

if anyone knows, in #3 above, how A can specify that "no b2 is
allowed!", i'd be curious.

cheers, Greg Minshall
----
setClass("A",
         representation(
           x="numeric"));

setMethod(
  f="initialize",
  signature="A",
  definition=function(.Object) {
    .Object@x <- 23;
    return(.Object)
  });

setGeneric("bB", function(me) standardGeneric("bB"));
setMethod(
  "bB",
  signature("A"),
  definition=function(b1) {
    return (new("B", b1@x))});

setClass("B", representation(
  bx="numeric"));

setMethod(
  "initialize",
  signature("B"),
  definition=function(.Object, x) {
    .Object@bx <- x;
    return(.Object);
  });

setGeneric("bB", function(b1, b2) standardGeneric("bB"));
setMethod(
  "bB",
  signature("B", "B"),
  definition=function(b1, b2) {
    return(new("B", min(b1@bx, b2@bx)))});

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Reply | Threaded
Open this post in threaded view
|

Re: 2 setGeneric's, same name, different method signatures

Martin Morgan
In reply to this post by Greg Minshall
On 2/14/2013 8:57 AM, Greg Minshall wrote:

> hi.  below is a small test case (hopefully minimal, though i'm still a
> bit confused about initializers).
>
> i would have guessed (and maybe i still would have been right) that one
> could re-use the name of a generic function for functions with different
> numbers of arguments.  in the case below, class A's bB() queries the
> status of a single A object, so bB(A) (where here "A" is an instance of
> class A, just for "clarity") returns a value.  class B's bB() compares
> values in two B objects, and returns the minimum, so bB(B1, B2) are its
> methods.
>
> after loading the file, i see the method for A's bB has disappeared (as
> measured by showMethods("bB"), as well as trying bB(A).  if i have R
> re-parse the setGeneric/setMethod  A's bB(), then B's bB() disappears.
>
> somehow my code, or my model of how things work, is wrong.  any ideas
> what am i missing?
>
> cheers, Greg Minshall
> ----
> setClass("A",
>           representation(
>             x="numeric"));
>
> setMethod(
>    f="initialize",
>    signature="A",
>    definition=function(.Object) {
>      .Object@x <- 23;
>      return(.Object)
>    });
>
> setGeneric("bB", function(me) standardGeneric("bB"));
> setMethod(
>    "bB",
>    signature("A"),
>    definition=function(me) {
>      return (new("B", me@x))});
>
> setClass("B", representation(
>    bx="numeric"));
>
> setMethod(
>    "initialize",
>    signature("B"),
>    definition=function(.Object, x) {
>      .Object@bx <- x;
>      return(.Object);
>    });
>
> setGeneric("bB", function(b1, b2) standardGeneric("bB"));

Hi Greg --

this setGeneric is over-writing the first, as would

f = function() "first"
f = function() "second"
f() # "second"

If you'd like to dispatch on a single argument, then

setGeneric("one", function(x, ...) standardGeneric("one"))
setMethod("one", "A", function(x, ...) "A-method")
setMetohd("one", "B", function(x, y, ...) "B-method")

The '...' in the generic allow you to add arguments that are 'picked off' by
methods. The user could provide any value for y, not only an object of class "B".

If you'd like to dispatch sometimes on two arguments then

setGeneric("two", function(x, y, ...) standardGeneric("two"))
setMethod("two", c("A", "ANY"), function(x, y, ...) "A,ANY-method")
setMethod("two", c("B", "B"), function(x, y, ...) "B,B-method")

then two(new("A")), two(new("A"), new("A")) and two(new("A"), new("B")) end up
in A,ANY,two-method while two(new("B"), new("B")) ends up in "B,B,two-method".
Other combinations are errors. One might instead not define A,ANY but instead

setMethod("two", c("A", "missing"), function(x, y, ...) "A,missing-method")

and then two(new("A"), new("A")) would be an error.

Multiple dispatch is complicated, and perhaps best to avoid if possible.

It's possible to write a generic and methods that dispatch on '...', with the
requirement that all classes are the same; this in the spirit of comparing two
B's and returning the smaller; see ?dotsMethods though again this is not a
trivial use case.

Hope that helps enough.

Martin

> setMethod(
>    "bB",
>    signature("B", "B"),
>    definition=function(b1, b2) {
>      return(new("B", min(b1@bx, b2@bx)))});
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.
>


--
Dr. Martin Morgan, PhD
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Reply | Threaded
Open this post in threaded view
|

Re: 2 setGeneric's, same name, different method signatures

Greg Minshall
Martin,

fantastic.  thank you *very* much!  that clears lots of things up for
me.

(for the record: i think that setGeneric overwriting a previous is more
surprising -- thus violating the principle of least surprise -- than one
function overwriting a previous, in that we think of (or, one way to
think of) OOP is that, after finagling to have no clashes on *class*
names, we should not worry about other than intra-class name clashes.
as i said, for the record.)

thanks again.

cheers, Greg
----
Martin Morgan <[hidden email]> wrote:

>
> Hi Greg --
>
> this setGeneric is over-writing the first, as would
>
> f = function() "first"
> f = function() "second"
> f() # "second"
>
> If you'd like to dispatch on a single argument, then
>
> setGeneric("one", function(x, ...) standardGeneric("one"))
> setMethod("one", "A", function(x, ...) "A-method")
> setMetohd("one", "B", function(x, y, ...) "B-method")
>
> The '...' in the generic allow you to add arguments that are 'picked
> off' by methods. The user could provide any value for y, not only an
> object of class "B".
>
> If you'd like to dispatch sometimes on two arguments then
>
> setGeneric("two", function(x, y, ...) standardGeneric("two"))
> setMethod("two", c("A", "ANY"), function(x, y, ...) "A,ANY-method")
> setMethod("two", c("B", "B"), function(x, y, ...) "B,B-method")
>
> then two(new("A")), two(new("A"), new("A")) and two(new("A"),
> new("B")) end up in A,ANY,two-method while two(new("B"), new("B"))
> ends up in "B,B,two-method". Other combinations are errors. One might
> instead not define A,ANY but instead
>
> setMethod("two", c("A", "missing"), function(x, y, ...) "A,missing-method")
>
> and then two(new("A"), new("A")) would be an error.
>
> Multiple dispatch is complicated, and perhaps best to avoid if possible.
>
> It's possible to write a generic and methods that dispatch on '...',
> with the requirement that all classes are the same; this in the spirit
> of comparing two B's and returning the smaller; see ?dotsMethods
> though again this is not a trivial use case.
>
> Hope that helps enough.
>
> Martin

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Reply | Threaded
Open this post in threaded view
|

Re: 2 setGeneric's, same name, different method signatures

William Dunlap
Earlier you wrote
> changing "me" to "b1" in A's bB(), allows A to use B's setGeneric()
and here mention "intra-class name clashes" (I'm not sure what you
mean by this).

In R, classes do not "own" (or contain) generic functions.  They can supply
methods for generic functions but a generic function is an object that
exists outside of any class.  C++ and Java do things differently.

Bill Dunlap
Spotfire, TIBCO Software
wdunlap tibco.com


> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf
> Of Greg Minshall
> Sent: Friday, February 15, 2013 3:35 AM
> To: Martin Morgan
> Cc: [hidden email]
> Subject: Re: [R] 2 setGeneric's, same name, different method signatures
>
> Martin,
>
> fantastic.  thank you *very* much!  that clears lots of things up for
> me.
>
> (for the record: i think that setGeneric overwriting a previous is more
> surprising -- thus violating the principle of least surprise -- than one
> function overwriting a previous, in that we think of (or, one way to
> think of) OOP is that, after finagling to have no clashes on *class*
> names, we should not worry about other than intra-class name clashes.
> as i said, for the record.)
>
> thanks again.
>
> cheers, Greg
> ----
> Martin Morgan <[hidden email]> wrote:
> >
> > Hi Greg --
> >
> > this setGeneric is over-writing the first, as would
> >
> > f = function() "first"
> > f = function() "second"
> > f() # "second"
> >
> > If you'd like to dispatch on a single argument, then
> >
> > setGeneric("one", function(x, ...) standardGeneric("one"))
> > setMethod("one", "A", function(x, ...) "A-method")
> > setMetohd("one", "B", function(x, y, ...) "B-method")
> >
> > The '...' in the generic allow you to add arguments that are 'picked
> > off' by methods. The user could provide any value for y, not only an
> > object of class "B".
> >
> > If you'd like to dispatch sometimes on two arguments then
> >
> > setGeneric("two", function(x, y, ...) standardGeneric("two"))
> > setMethod("two", c("A", "ANY"), function(x, y, ...) "A,ANY-method")
> > setMethod("two", c("B", "B"), function(x, y, ...) "B,B-method")
> >
> > then two(new("A")), two(new("A"), new("A")) and two(new("A"),
> > new("B")) end up in A,ANY,two-method while two(new("B"), new("B"))
> > ends up in "B,B,two-method". Other combinations are errors. One might
> > instead not define A,ANY but instead
> >
> > setMethod("two", c("A", "missing"), function(x, y, ...) "A,missing-method")
> >
> > and then two(new("A"), new("A")) would be an error.
> >
> > Multiple dispatch is complicated, and perhaps best to avoid if possible.
> >
> > It's possible to write a generic and methods that dispatch on '...',
> > with the requirement that all classes are the same; this in the spirit
> > of comparing two B's and returning the smaller; see ?dotsMethods
> > though again this is not a trivial use case.
> >
> > Hope that helps enough.
> >
> > Martin
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Reply | Threaded
Open this post in threaded view
|

Re: 2 setGeneric's, same name, different method signatures

Greg Minshall
In reply to this post by Greg Minshall
William,

> and here mention "intra-class name clashes" (I'm not sure what you
> mean by this).

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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Reply | Threaded
Open this post in threaded view
|

Re: 2 setGeneric's, same name, different method signatures

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


> -----Original Message-----
> From: Greg Minshall [mailto:[hidden email]]
> Sent: Friday, February 15, 2013 1:37 PM
> To: William Dunlap
> Cc: [hidden email]
> Subject: Re: 2 setGeneric's, same name, different method signatures
>
> William,
>
> > and here mention "intra-class name clashes" (I'm not sure what you
> > mean by this).
>
> 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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Reply | Threaded
Open this post in threaded view
|

Re: 2 setGeneric's, same name, different method signatures

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 <[hidden email]> wrote:

> 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
>
>
>> -----Original Message-----
>> From: Greg Minshall [mailto:[hidden email]]
>> Sent: Friday, February 15, 2013 1:37 PM
>> To: William Dunlap
>> Cc: [hidden email]
>> Subject: Re: 2 setGeneric's, same name, different method signatures
>>
>> William,
>>
>> > and here mention "intra-class name clashes" (I'm not sure what you
>> > mean by this).
>>
>> 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
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.



--
Chief Scientist, RStudio
http://had.co.nz/

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Reply | Threaded
Open this post in threaded view
|

Re: 2 setGeneric's, same name, different method signatures

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@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.
Reply | Threaded
Open this post in threaded view
|

Re: 2 setGeneric's, same name, different method signatures

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

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

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

   ShortRead::chromosome

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

maybe; you should have in your DESCRIPTION file

   Imports: ShortRead

and in your NAMESPACE file

   importFrom(ShortRead, chromosome)

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

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)


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

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.

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

Yes to some extent there are fewer conflicts -- inside your package -- when
using a 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.

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


>
> 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.
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.
>


--
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109

Location: Arnold Building M1 B861
Phone: (206) 667-2793

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Reply | Threaded
Open this post in threaded view
|

Re: 2 setGeneric's, same name, different method signatures

Greg Minshall
In reply to this post by hadley wickham
the world's most minor typo on
https://github.com/hadley/devtools/wiki/Rcpp
----
optimisiation

helpful page, btw!  thanks!

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Reply | Threaded
Open this post in threaded view
|

Re: 2 setGeneric's, same name, different method signatures

Greg Minshall
In reply to this post by hadley wickham
(apologies for not having edited the to/cc list!!!!)

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Reply | Threaded
Open this post in threaded view
|

Re: 2 setGeneric's, same name, different method signatures

Romain Fenouil
In reply to this post by Martin Morgan
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.