Skip to content

S4 generic not exported correctly / incorrect dispatch?

3 messages · Martin Maechler, Martin Morgan

Original
Martin Morgan
# 
In this post

   https://stat.ethz.ch/pipermail/bioc-devel/2013-March/004152.html

a package author reports that S4 dispatch fails. I can reproduce this with a 
PkgA (attached; 'intervals' is a relatively light-weight CRAN package) that has 
DESCRIPTION with

Depends: intervals
Imports: graphics

NAMESPACE:

importFrom(graphics, "plot")
export("plot")
exportMethods("plot")

R/tmp.R

setClass("A")
setMethod("plot", "A", function(x, y, ...) {})


and then

 > library(PkgA)
Loading required package: intervals
 > plot
function (x, y, ...)
UseMethod("plot")
<environment: namespace:graphics>

notice that 'plot' is reported as an S3 generic, but should be an S4 generic.

Removing Depends: intervals or changing to importsFrom(intervals, "plot") 
recovers S4 export

 > library(PkgA)
Loading required package: intervals
 > plot
standardGeneric for "plot" defined from package "graphics"

function (x, y, ...)
standardGeneric("plot")
<environment: 0x60aea90>
Methods may be defined for arguments: x, y
Use  showMethods("plot")  for currently available ones.


The 'intervals' package Depends: on methods but nothing else. It defines S3 and 
S4 methods on plot, creating an implicit S4 generic in the process. It's 
NAMESPACE has

S3method( "plot", "Intervals" )
S3method( "plot", "Intervals_full" )
exportMethods("plot")

and we have

 > library(intervals)
 > plot
standardGeneric for "plot" defined from package "graphics"

function (x, y, ...)
standardGeneric("plot")
<environment: 0x68cdc78>
Methods may be defined for arguments: x, y
Use  showMethods("plot")  for currently available ones.

I think everyone is playing by the rules, and that plot should be reported as an 
S4 generic in girafe / PkgA?

 > sessionInfo()
R Under development (unstable) (2013-03-13 r62241)
Platform: x86_64-unknown-linux-gnu (64-bit)

locale:
  [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C
  [3] LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8
  [5] LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8
  [7] LC_PAPER=C                 LC_NAME=C
  [9] LC_ADDRESS=C               LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base

other attached packages:
[1] PkgA_1.2.3       intervals_0.14.0

This is also seen in

 > sessionInfo()
R version 3.0.0 alpha (2013-03-13 r62244)
Platform: x86_64-unknown-linux-gnu (64-bit)


Martin
1 day later
Martin Maechler
# 
> In this post
    > https://stat.ethz.ch/pipermail/bioc-devel/2013-March/004152.html

    > a package author reports that S4 dispatch fails. I can reproduce this with a 
    > PkgA (attached; 'intervals' is a relatively light-weight CRAN package) that has 
    > DESCRIPTION with

    > Depends: intervals
    > Imports: graphics

    > NAMESPACE:

    > importFrom(graphics, "plot")
    > export("plot")
    > exportMethods("plot")

    > R/tmp.R

    > setClass("A")
    > setMethod("plot", "A", function(x, y, ...) {})


    > and then

    >> library(PkgA)
    > Loading required package: intervals
    >> plot
    > function (x, y, ...)
    > UseMethod("plot")
    > <environment: namespace:graphics>

    > notice that 'plot' is reported as an S3 generic, but should be an S4 generic.

    > Removing Depends: intervals or changing to importsFrom(intervals, "plot") 
    > recovers S4 export

Indeed.

What happens is the following:

Because of the 'Depends: intervals',
the setMethod("plot", A", ...) 
is *NOT* implicitly creating a new S4 plot() generic,
but rather sees the existing S4 plot generic in 'intervals' and
attaches its method there.
But as "you" fail to import plot from intervals, that is not
"seen" because it is masked by the S3 generic plot which you do
explicitly import from graphics.

If you (well the 'girafe' package author) really want to define
and export both S3 and S4 generics for plot, you should
ensure that you either import an S4 generic (from 'intervals', e.g.),
*or* that you explicitly create one yourself, using
setGeneric("plot", ..)  to be in your own name space.
[But of course, the latter is not really what you'd want, I think].

Why are you opposed to   
    importsFrom(intervals, "plot") 
?

I agree that it is ``asymmetric'' that you must think about how
to get plot as S4 generic,  *because* you depend on a package
that defines plot as S4 generic,
whereas that package does not have to do the same.

I think we have to live with this infelicity of 
interaction of namespace and S4 designs.

Martin

    >> library(PkgA)
    > Loading required package: intervals
    >> plot
    > standardGeneric for "plot" defined from package "graphics"

    > function (x, y, ...)
    > standardGeneric("plot")
    > <environment: 0x60aea90>
    > Methods may be defined for arguments: x, y
    > Use  showMethods("plot")  for currently available ones.


    > The 'intervals' package Depends: on methods but nothing else. It defines S3 and 
    > S4 methods on plot, creating an implicit S4 generic in the process. It's 
    > NAMESPACE has

    > S3method( "plot", "Intervals" )
    > S3method( "plot", "Intervals_full" )
    > exportMethods("plot")

    > and we have

    >> library(intervals)
    >> plot
    > standardGeneric for "plot" defined from package "graphics"

    > function (x, y, ...)
    > standardGeneric("plot")
    > <environment: 0x68cdc78>
    > Methods may be defined for arguments: x, y
    > Use  showMethods("plot")  for currently available ones.

    > I think everyone is playing by the rules, and that plot should be reported as an 
    > S4 generic in girafe / PkgA?

    >> sessionInfo()
    > R Under development (unstable) (2013-03-13 r62241)
    > Platform: x86_64-unknown-linux-gnu (64-bit)

    > locale:
    > [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C
    > [3] LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8
    > [5] LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8
    > [7] LC_PAPER=C                 LC_NAME=C
    > [9] LC_ADDRESS=C               LC_TELEPHONE=C
    > [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C

    > attached base packages:
    > [1] stats     graphics  grDevices utils     datasets  methods   base

    > other attached packages:
    > [1] PkgA_1.2.3       intervals_0.14.0

    > This is also seen in

    >> sessionInfo()
    > R version 3.0.0 alpha (2013-03-13 r62244)
    > Platform: x86_64-unknown-linux-gnu (64-bit)


    > Martin
    > -- 
    > Computational Biology / Fred Hutchinson Cancer Research Center
    > 1100 Fairview Ave. N.
    > PO Box 19024 Seattle, WA 98109

    > Location: Arnold Building M1 B861
    > Phone: (206) 667-2793
    > x[DELETED ATTACHMENT external: PkgA_1.2.3.tar.gz, application/x-gzip]
    > ______________________________________________
    > R-devel at r-project.org mailing list
    > https://stat.ethz.ch/mailman/listinfo/r-devel
Martin Morgan
#
On 03/15/2013 04:42 AM, Martin Maechler wrote:
Thanks for your help and insight, Martin.

There _was_ a change to intervals, overlooked in the other various moving parts, 
with exportMethods(plot) added to the NAMESPACE.

So setMethod is finding and adding to the generic on the search path, but 
exporting the (not implicitly promoted) S3 generic imported from graphics.

The 'surprise' is that plot on the search path wins out over plot in the name space.

I think (?) I would have been 'surprised' later when PkgA's exportMethods(plot) 
did not merge the methods on the implicit generic in PkgA with the implicit 
generic on the search path, especially if PkgA had not also export(plot).
Conceptually, I'm implementing a method orthogonal to what other packages are doing.

Practically, I'd like my name space to insulate me from what other packages do.

Thanks a lot for your help, I understand what is going on.

Martin