Who to decide what a generic function should look like?
-----Original Message----- From: r-devel-admin@stat.math.ethz.ch [mailto:r-devel-admin@stat.math.ethz.ch] On Behalf Of Duncan Murdoch Sent: den 22 februari 2003 03:15 To: Henrik Bengtsson Cc: r-devel@stat.math.ethz.ch Subject: [Rd] Re: [R] Who to decide what a generic function should look like? 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.
I understand this viewpoint too, but I tend to think about it as follows. Consider a hierarchy of all possible classes. Excluding multiple heritance, they could I principle be place in a tree structure with a root class, which all classes directly or indirectly inherits from (this is the idea in for instance Java). In R, such a root class could have the methods print(), as.character() and a few other methods that you expect all R objects to have. From there on you add new classes. With this class hierarchy I think about generic functions (as they work today) as methods that are placed in the root object. However, why can they not be further down the tree where they can be documented specifically for that subtree and provide polymorphism from there on? This should still be (be even more) intutive for the end user I think. So not thinking about S3 or S4, but in a longer term, is there a reason for not going the whole way and having a method dispatching mechanism that is totally general like in other object-oriented languages? When asking this, I might reveal that I am not fully confortable with the differences and pros & cons between scientific programming (with vectors) and standard object-oriented programming.
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).
This is promising and I am really glad to hear that the problem of conflicts might be solved. The problem remains though if one decides to have to different types of classes in one package both with a normalize() method, meaning that you might have to split up your package into a bundle of packages. However, this is a much smaller problem since it can be controlled by the developer.
* 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
Duncan, thanks a lot for your reply! Henrik