Explore group generics implementation

[hadley]

Fixes #353

[hadley]

To do:

• Actually implement the behaviour
• Pull fallback technique from Ensure Ops falls back to base behaviour #382
• Think about user experience. What object will they define a method for? Probably S7_Ops etc + methods::Ops
• Where should this be documented?

[hadley]

@t-kalinowski @DavisVaughan before I finish up the implementation for the other group generics, could you please take a look at how it works for Math?

[DavisVaughan]

Looks nice to me!

[DavisVaughan]

Do we need to call NextMethod()? Isn't S7_object always the right-most class? It would be nice to throw the S7 method not found error if we could

[DavisVaughan]

Should this all live in method-group.R now?

[DavisVaughan]

Do you also need to check for a "specific" generic call here?

[t-kalinowski]

This looks like a very nice solution. I see no issues.

[mmaechler]

Sorry if I'm a "game spoiler": Using tryCatch() in such fundamental group's methods will I think be quite a performance killer e.g. for simple arithmetic / math operations.
Is that really really necessary?

[hadley]

If you can suggest an alternative implementation, I'm happy to try it. But I couldn't think of another way to do it.

[t-kalinowski]

One approach might be to update method_ and method_call_ (c functions), so that, rather than than signaling an error directly, they return a sentinel value like NULL, or perhaps, the error call itself (i.e., calling eval() on the return object signals the error). Then, instead of calling S7_dispatch() in the S7_Math() generic, we could inspect for the sentinel instead. For example, S7_Math() could be defined like this:

S7_Math <<- new_generic("Math", "x", function(x, ..., .Generic) {
  cl <- .Call(method_call_, sys.call(), sys.function(), sys.frame())
  if(is.null(cl)) 
    NextMethod()
  else 
    eval(cl)
})

[mmaechler]

One approach might be to update method_ and method_call_ (c functions), so that, rather than than signaling an error directly, they return a sentinel value like NULL, or perhaps, the error call itself (i.e., calling eval() on the return object signals the error). Then, instead of calling S7_dispatch() in the S7_Math() generic, we could inspect for the sentinel instead.
For example ...

"Nice"! That would almost surely be an order of magnitude faster!

Possibly we'd even want to provide (and document and use ourselves) a thin wrapper around .Call(..) such that S7-users could make use of this as well in their own method definitions.
{{I do acknowledge I haven't studied what you are doing exactly here, so "I have no clue" ;-)}}

[hadley]

Ok, I'll take a stab at that approach.