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

Reply via email to