For information on using this system, please visit this page.

Bug 16929 - Repeated call of overloaded individual S4 functions of Math / Ops / Arith group fails
Summary: Repeated call of overloaded individual S4 functions of Math / Ops / Arith gro...
Status: CLOSED FIXED
Alias: None
Product: R
Classification: Unclassified
Component: S4methods (show other bugs)
Version: R 3.3.*
Hardware: x86_64/x64/amd64 (64-bit) Linux
: P5 normal
Assignee: R-core
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-05-30 12:48 UTC by David Rügamer
Modified: 2016-06-07 13:49 UTC (History)
2 users (show)

See Also:


Attachments
repeated call of overloaded abs operator fails (2.10 KB, text/x-r-source)
2016-05-30 12:48 UTC, David Rügamer
Details

Note You need to log in before you can comment on or make changes to this bug.
Description David Rügamer 2016-05-30 12:48:23 UTC
Created attachment 2098 [details]
repeated call of overloaded abs operator fails

As already mentioned in 2012 and 2015 in the following SO threads

http://stackoverflow.com/questions/13812373/overloading-operator-in-r-s4-classes-and-matrix-package

http://stackoverflow.com/questions/34221612/setmethod-and-package-matrix

overloading individual S4 functions in the group functions Math, Ops or Arith does work on the first time but fails for repeated calls with the error message

object '.Generic' not found

. Though this bug occurs in particular in conjunction with the Matrix package, the unexpected behaviour is attributed to R itself.
Comment 1 David Rügamer 2016-06-01 10:50:06 UTC
PS: This seems to be only a problem when overloading methods outside of a package. Overloading an individual function within a package makes R to look at the right place.
Comment 2 Michael Lawrence 2016-06-01 12:24:12 UTC
The methods package has two implementations of dispatch: internal and standardGeneric(). The combination of setting a method on a "member" generic and caching leads to the internal mechanism. The internal mechanism does not set .Generic, perhaps for performance reasons. Right now callGeneric() and callNextMethod() rely on the heuristic of introspecting the call to get the generic when .Generic is missing. It would help to get John's opinion on this. Should the internal mechanism just set .Generic as PRIMNAME(op)?
Comment 3 John Chambers 2016-06-01 16:25:04 UTC
There were many problems with primitive functions.  Special treatments were often because there is no generic function, e..g, corresponding to the "generic" slot in the method definition object.  I don't remember any details of this particular choice.

In principle, yes it would be sensible to set .Generic, but with primitives weird side effects are common.
Comment 4 Michael Lawrence 2016-06-07 13:49:54 UTC
Went ahead and made internal dispatch set .Generic.