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