search for: method_bodi

I wish it didn't have to depend on the name '.local'. Back when I wrote a lot of S4 methods I avoided the auto-generated .local and named the local function something that made sense so that is was easier for a user to track down the source of an error. E.g., define the generic QQQ with numeric and integer methods: setGeneric("QQQ", function(x, ...)NULL)

Would we really need the special class or would simply checking the formals of the method against those of the generic be simple and fast enough? On Thu, Jan 29, 2015 at 9:41 AM, John Chambers <jmc at r-project.org> wrote: > I wouldn't want to add more to the current approach; if someone would like > to devote some time, the much preferable idea IMO would be to replace the >

On Thu, Jan 29, 2015 at 7:57 AM, John Chambers <jmc at r-project.org> wrote: > > On Jan 28, 2015, at 6:37 PM, Michael Lawrence <lawrence.michael at gene.com> wrote: > >> At this point I would just due: >> >> formals(body(method)[[2L]]) >> >> At some point we need to figure out what to do with this .local() confusion. > > Agreed, definitely.

On Jan 28, 2015, at 6:37 PM, Michael Lawrence <lawrence.michael at gene.com> wrote: > At this point I would just due: > > formals(body(method)[[2L]]) > > At some point we need to figure out what to do with this .local() confusion. Agreed, definitely. The current hack is to avoid re-matching arguments on method dispatch, so a fix would need to be fairly deep in the

I wouldn't want to add more to the current approach; if someone would like to devote some time, the much preferable idea IMO would be to replace the whole mechanism. Here's one suggestion: 1. have a class, say "nonConformingMethod" for method definitions that diverge in the argument list. 2. the internal dispatch code checks the class of the selected definition (this can