[Rd] Re: [R] Who to decide what a generic function should look like?

[Duncan Murdoch]

On Thu, 20 Feb 2003 13:05:44 +1100, you wrote in message
<000d01c2d884$98690fa0$7341a8c0@alpha.wehi.edu.au>:

>I am not sure if what I am asking below should be discussed under r-help
>or r-devel, so please feel free to move over to r-devel. 

I've done that, I think it's a more r-devel kind of topic.

>For me a generic function should be fully generic in the sense that
>there are no requirements of arguments agreement (and therefore it
>should not be documented as a reply to Smyth's thread). 

I don't agree.  A generic function has a meaning.  Often that meaning
is expressed in terms of certain arguments.  If a user of an unknown
object knows that it supports the generic, they have a right to expect
it to behave according to the standard meaning of the generic.

>My concern is that enforcing methods to match the argument signature of
>the generic function will make packages incompatible with each other. I
>can not create a generic function called "normalize" for my microarray
>package and expect it to work together with other package defining a
>generic function with the same name. Some short-term and long-term
>outcomes from this are:

That's only a short term problem.  As namespaces arrive, it will go
away.  Your normalize will not trample on anyone else's normalize,
because your names will live in a different namespace.  Hopefully the
default behaviour will be reasonable (i.e. if I say "normalize", and
only one version is around, I'll get it; if there are two, there'll be
either a clear way to choose, or a warning or error about the
ambiguity).

>  * who is the person to decide what a generic function should look
>like, and 
>  * who owns the right to the method name "normalize"?

The author of the package makes the decisions and owns the names in
that package.

Duncan Murdoch