[Rd] Re: [R] Who to decide what a generic function should look like?
Fri Feb 21 17:15:04 2003
On Thu, 20 Feb 2003 13:05:44 +1100, you wrote in message
>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
> * who is the person to decide what a generic function should look
> * who owns the right to the method name "normalize"?
The author of the package makes the decisions and owns the names in