On Thu, 20 Feb 2003 13:05:44 +1100, you wrote in message <000d01c2d884$98690fa0$[EMAIL PROTECTED]>:
>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 ______________________________________________ [EMAIL PROTECTED] mailing list http://www.stat.math.ethz.ch/mailman/listinfo/r-devel
