Thank you, Lars, for persisting on this topic of
missing S4 generics!
[I'm diverting this away from the original bug report;
since this is really about future features rather than R bugs.]
Unfortunately it's not as easy as you might think.
o One reason is the fact that currently it is still necessary
for bootstrapping reasons that R "can run" with only the 'base'
package loaded, i.e. "methods" not available. This makes
it sometimes hard to S4-ize base functions.
o Then there have been performance issues hindering the
S4-ification of ``everything''.
Note that e.g. S4 classes , functions methods, etc are not really
proper C-level SEXPs which would speed up (and lead to clean
up) of the "methods" code base.
o One other problem is with function like cbind() which have
a signature starting with '...' : The need to be changed
before you can define methods for them.
We've recently started to discuss this issue within R core,
with constructive proposals by John Chambers, and I have been
strongly considering indeed to try the case of
cbind() and rbind() in particular.
I also hope that some of these issues will be addressed during
this summer and will eventually lead to much improved S4
facilities in R.
Martin Maechler, ETH Zurich
>>>>> "lars" == lars <[EMAIL PROTECTED]>
>>>>> on Fri, 15 Jul 2005 01:26:50 +0200 (CEST) writes:
lars> Hi,
lars> I ran into another internal function that is missing S4 dispatch. It
is
lars> the binary operator ":". Looking at the code, I see that it is
actually
lars> a common problem. Other candidates are operators like "~", "&&", "||"
lars> and functions like: "length<-", "row", "col", "unlist", "cbind", etc.
It
lars> would for instance be nice to be able to write a matrix class that
has
lars> the same operators and functions as the built-in class. In general, I
lars> think that all the operators and functions associates with built-in
lars> types like vectors, lists, matrices and data frames should have S4
dispatch.
lars> Thanks,
lars> Lars
lars> lars wrote:
>> Hi,
>>
>> OK, if you try to explicitly make them generic, you are told that they
>> are implicitly already generic:
>>
>> > setGeneric("is.finite", function(from, ...)
>> standardGeneric("is.finite"))
>> Error in setGeneric("is.finite", function(from, ...)
>> standardGeneric("is.finite")) :
>> "is.finite" is a primitive function; methods can be defined, but
>> the generic function is implicit, and can't be changed.
>>
>> If you query about its genericness before you define you own generic,
>> you get:
>>
>> > isGeneric("is.finite")
>> [1] FALSE
>>
>> But after you define you own generic, you get:
>>
>> > setMethod("is.finite", signature(x="TS"),
>> + function(x) {
>> + Data(x) = callNextMethod()
>> + x
>> + })
>> [1] "is.finite"
>>
>> > isGeneric("is.finite")
>> [1] TRUE
>>
>> This all makes some sense, but I am not familiar enough with he
>> internals to explain exactly why it is done this way. I think you will
>> fine that 'is.nan' behave exactly the same way.
>>
>> Thanks,
>> Lars
>>
>>
>> Prof Brian Ripley wrote:
>>
>>> These functions are not generic according to the help page.
>>> The same page says explicitly that is.nan is generic.
>>>
>>> Where did you get the (false) idea that they were generic?
>>>
>>> On Thu, 16 Jun 2005 [EMAIL PROTECTED] wrote:
>>>
>>>> Full_Name: Lars Hansen
>>>> Version: 2.1.0
>>>> OS: SunOS 5.8
>>>> Submission from: (NULL) (207.66.36.189)
>>>>
>>>>
>>>> Hi,
>>>>
>>>> S4 method displacth does not work for the two generic functions
>>>> 'is.finite' and 'is.infinite'. It turns out that the C functions
>>>> 'do_isfinite' and 'do_isinfinite' in src/main/coerce.c are missing a
>>>> call to 'DispatchOrEval' (see do_isnan). Added in the call fixed the
>>>> problem. My functions no look like this:
>>>>
>>>> Form coerce.c:
>>>>
>>>> SEXP do_isfinite(SEXP call, SEXP op, SEXP args, SEXP rho)
>>>> {
>>>> SEXP ans, x, names, dims;
>>>> int i, n;
>>>>
>>>> if (DispatchOrEval(call, op, "is.finite", args, rho, &ans, 1, 1))
>>>> return(ans);
>>>>
>>>> checkArity(op, args);
>>>> ...
>>>>
>>>> SEXP do_isinfinite(SEXP call, SEXP op, SEXP args, SEXP rho)
>>>> {
>>>> SEXP ans, x, names, dims;
>>>> double xr, xi;
>>>> int i, n;
>>>>
>>>> if (DispatchOrEval(call, op, "is.infinite", args, rho, &ans, 1, 1))
>>>> return(ans);
>>>>
>>>> checkArity(op, args);
>>>> ...
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
