R devel - Feb 2003 - Who to decide what a generic function should look like?

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. 

This is a spin off from Gordon Smyth's question about generic functions
and Robert Gentleman's reply. I have tried to raise the question before
and I am sure this has been discussed by others, but never on the r-help
list what I can see. My concern is that generic functions as defined
today are only semi-generic. From ?Methods the definition of a generic
function is:

     "A generic function is a function that has associated with it a
     collection of other functions (the methods), all of which agree in
     formal arguments with the generic."

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). Under the
S3/UseMethod scheme as well S4/methods scheme this requirement is
enforced (even though one can get around it by using only arguments
"...") and under S4/methods it is followed even more strictly. I
understand that by enforcing matching arguments (and argument types) the
method dispatching mechanism can work much faster. Are there any another
purposes than efficiency behind the argument matching requirement? Why
not make a generic function truly generic? Having truly generic
functions, the method dispatching mechanism could equally well be done
by the language interpreter itself and thus making generic functions
obsolete.


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:

  * Each developer who cares has to come up with a less general name
than "normalize", e.g. 
    "normalizeLowess". However, this will still not guarantee you that
there will not be any 
    naming conflict with other, to you unknown or future upcoming,
packages. People will have 
    to create extremely awkward method names to make there generic
functions unique. This is
    already happening today (and unfortunately everyone invents his/her
own naming rules).

  * This in turn will result in an object-oriented programming style
that looks like a 
    procedural programming style and the gain/idea of having
polymorphism and the possibility 
    of overloading methods will disappear. This can also be seen in some
packages.

  * If you do not follow the approach of having unique method names, but
still want to keep your 
    package compatible with other, you will have to change your API
constantly, which hurt the 
    end user who has to update there scripts accordingly. This will also
result in unnecessary 
    troubleshooting and bug fixes.

  * Trying to learn object-oriented programming by using R will be
confusing, resulting in 
    procedural/object-oriented hybrids. This can also be seen today.

Does anyone agree with this and what are the thoughts about this?

So,

  * who is the person to decide what a generic function should look
like, and 
  * who owns the right to the method name "normalize"?

Best wishes

Henrik Bengtsson

Home: 201/445 Royal Parade, 3052 Parkville
Office: Bioinformatics, WEHI, Parkville
+61 (0)412 269 734 (cell), +61 (0)3 9345 2324 (lab),
+1 (508) 464 6644 (global fax)
hb at wehi.edu.au, http://www.maths.lth.se/~hb/
Time zone: +11h UTC (Sweden +1h UTC, Calif. -8h UTC)

On Thu, 20 Feb 2003 13:05:44 +1100
Henrik Bengtsson <hb at maths.lth.se> wrote:
> 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. 
> 
> This is a spin off from Gordon Smyth's question about generic functions
> and Robert Gentleman's reply. I have tried to raise the question before
> and I am sure this has been discussed by others, but never on the r-help
> list what I can see. My concern is that generic functions as defined
> today are only semi-generic. From ?Methods the definition of a generic
> function is:
> 
>      "A generic function is a function that has associated with it a
>      collection of other functions (the methods), all of which agree in
>      formal arguments with the generic."
> 
> 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). Under the
> S3/UseMethod scheme as well S4/methods scheme this requirement is
> enforced (even though one can get around it by using only arguments
> "...") and under S4/methods it is followed even more strictly. I
> understand that by enforcing matching arguments (and argument types) the
> method dispatching mechanism can work much faster. Are there any another
> purposes than efficiency behind the argument matching requirement? Why
> not make a generic function truly generic? Having truly generic
> functions, the method dispatching mechanism could equally well be done
> by the language interpreter itself and thus making generic functions
> obsolete.
> 
. . .
> Henrik Bengtsson
> 
I agree completely with Henrik about the problems caused by argument agreement. 
This has caused me a great deal of trouble.  As an example, I have many
functions for converting S objects to LaTeX, with parallel functions for
printing or plotting.  If I latex( ) a regression model fit, the types of LaTeX
options that apply are drastically different than if I latex( ) a data frame for
making a table with minor and major groupings.  A very small number of arguments
are in common.  I tried converting latex( ) to use the new methods some time
ago, and had to abondon the effort to large extent because of this problem.
-- 
Frank E Harrell Jr              Prof. of Biostatistics & Statistics
Div. of Biostatistics & Epidem. Dept. of Health Evaluation Sciences
U. Virginia School of Medicine  http://hesweb1.med.virginia.edu/biostat

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