> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Duncan Murdoch > Sent: den 22 februari 2003 03:15 > To: Henrik Bengtsson > Cc: [EMAIL PROTECTED] > 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 > <[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.
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 ______________________________________________ [EMAIL PROTECTED] mailing list http://www.stat.math.ethz.ch/mailman/listinfo/r-devel
