A reasonable goal, but for 2.5.x, not 2.4.0, would be to extend a
mechanism already in place to allow setMethod() calls for functions in
the base package, even though those functions have no directly visible
generic function definition. The recent changes to method dispatch
should help.
For many primitives (but not all and not for non-primitives) there is
already a stored generic function (e.g. getGeneric("+")) which is used
when a setMethod call is applied.
We could extend the mechanism to as many functions in base as made
sense, including the option of having a different set of formal
arguments. For non-primitives, the stored generic would be copied to
the base package environment, but only in an R session that was using
methods for this function.
Sometime after the dust settles from 2.4.0, I hope to experiment with an
arrangement on these lines.
John
Martin Maechler wrote:
>>>>>> "Robin" == Robin Hankin <[EMAIL PROTECTED]>
>>>>>> on Thu, 7 Sep 2006 12:18:51 +0100 writes:
>>>>>>
>
> Robin> Thank you for this. Minimal self-contained code included below.
> Robin> It is slightly modified from the original because brob objects
> have two
> Robin> slots, both of which are needed by c().
>
> Robin> [
> Robin> A "brob" obect is represents a real number with two slots: "x"
> holds
> Robin> its natural
> Robin> logarithm; slot "positive" is Boolean, indicating whether the
> number
> Robin> is positive.
> Robin> I want this because I need to manipulate numbers up to ~1e20000.
> Robin> The hard bit is addition: log(exp(x) + exp(y)) == x +
> log1p(exp(y-x))
> Robin> ]
>
> I know and I really like your idea.
> However....
>
> Robin> It seemed to make sense to coerce non-brob arguments to brobs,
> Robin> then make cPair() use cPairOfBrobs() [with coerced arguments] in
> Robin> three of the cases, and c() for the fourth with signature c("ANY",
>
> Robin> "ANY").
>
> Robin> Now below, JC states that "cWithMethods() _replaces_ the ordinary
> c
> Robin> (), it's not
> Robin> just a method for it". Does this imply that one cannot set up an
> R
> Robin> package
> Robin> so that the following code:
>
> Robin> x <- as.brob(1:10)
> Robin> x1 <- c(1,x)
> Robin> x2 <- c(x,1)
>
> Robin> works as expected?
>
> No. There's no way {which does not break much other R code} currently.
> More than two days ago,
> I had told you (and the R-devel readers) that you should look at
> help(cbind2) {and said why}.
> If you *really* look at it, and then
> think about or better study the code underlying
> the methods:::bind_activation(TRUE)
> kludge,
> you will shudder (and run :-) and probably understand that a
> similar kludge for c() is not appropriate.
>
> Robin> Or is there some workaround that would enable me to do this?
>
> well, yes: As John Chambers has tried to say, you have to teach
> your users to use cWithPairs() or c2() or myC() or c.() or any
> reasonable name, but not c().
>
> Martin
>
>
[[alternative HTML version deleted]]
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
