[Rd] Re: [R] Who to decide what a generic function should look like?

[Henrik Bengtsson]

> -----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