Skip to content

[R-pkg-devel] Extending an S3 method, but putting the package in Suggests?

6 messages · David Hugh-Jones, Martin Maechler

Original
David Hugh-Jones
# 
Hi,

Cross-posted from SO:
http://stackoverflow.com/questions/42776058/extending-an-s3-generic-from-an-optional-package

I have a package which provides an as.FlexTable method for its objects,
extending the S3 generic from the ReporteRs package. So, my NAMESPACE file,
generated by roxygen, has lines:

importFrom(ReporteRs,as.FlexTable)
...
S3method(as.FlexTable,huxtable)
...
export(as.FlexTable)

I don't much want to put ReporteRs in Imports: in the DESCRIPTION file,
because it involves a big external dependency on Java. But, when I put it
into Suggests:, R CMD check gives me errors like "Namespace dependency not
required".

Is there anyway I can extend the generic without making a hard dependency?

Cheers,
David
Martin Maechler
# 
> Hi,
    > Cross-posted from SO:
    > http://stackoverflow.com/questions/42776058/extending-an-s3-generic-from-an-optional-package

  ((sent my answer there as well))

    > I have a package which provides an as.FlexTable method for its objects,
    > extending the S3 generic from the ReporteRs package. So, my NAMESPACE file,
    > generated by roxygen, has lines:

    > importFrom(ReporteRs,as.FlexTable)
    > ...
    > S3method(as.FlexTable,huxtable)
    > ...
    > export(as.FlexTable)

    > I don't much want to put ReporteRs in Imports: in the DESCRIPTION file,
    > because it involves a big external dependency on Java. But, when I put it
    > into Suggests:, R CMD check gives me errors like "Namespace dependency not
    > required".

    > Is there anyway I can extend the generic without making a hard dependency?

No.  Importing is a hard dependency..
Some people do not import formally but use  '<pkgNamespace>::<obj>'
instead, *and* conditionalize their code on the availability of
that namespace.
I don't recommend that at all, and particularly not for
extending a generic.

I recommend you talk with the maintainer of 'ReporteRs':
1) You could use a common (yet-to-create) very small package say 'flexS3generics'
   which provides S3 generics (and S4 if ..) you want to use
   both, and then both you and her/him import from that mini package.
   You'd be both authors of that package.

2) If your package is much smaller (in its footprint, incl
   dependencies) than 'ReporteRs' she/he may agree to import the
   S3 generic from your package instead of the other way around.

Both are clean solutions,
and both need some time-coordination when releasing to CRAN,
'1)' being easier: Once the 'flexS3generics' is released to
CRAN, change (both) your package(s) to
importFrom(flexS3generics,*) but these changes and CRAN
submissions are then independent of each other.


    > Cheers,
    > David
David Hugh-Jones
# 
Thank you for this info and the suggestion!
David

On Tue, 14 Mar 2017 at 09:06, Martin Maechler <maechler at stat.math.ethz.ch>
wrote:
Sent from Gmail Mobile
David Hugh-Jones
# 
Just out of interest, what would happen if I used the hacky solution of
simply  exporting my own method like:

as.FlexTable <- function(x, ...) UseMethod("as.FlexTable")

 I am fairly sure you will tell me that fire and brimstone will rain down?
But it sure seems simple  compared to writing another package and getting
it on CRAN...

David

On Tue, 14 Mar 2017 at 09:06, Martin Maechler <maechler at stat.math.ethz.ch>
wrote:
Sent from Gmail Mobile
Martin Maechler
# 
> Just out of interest, what would happen if I used the hacky solution of
    > simply  exporting my own method like:

    > as.FlexTable <- function(x, ...) UseMethod("as.FlexTable")

    > I am fairly sure you will tell me that fire and brimstone will rain down?
    > But it sure seems simple  compared to writing another package and getting
    > it on CRAN...

no fire etc, but pretty close ;-)

You will have two (internal) methods tables for as.FlexTable,
one in ReporteRs, one in your package, and from a user point of
view there's a deep abyss in functionality between working with

  require(ReporteRs); require(huxtable)

and working with

  require(huxtable); require(ReporteRs)

This is undesirable and error prone and can be resolved by
correct imports as those mentioned.

Martin

    > David

    > On Tue, 14 Mar 2017 at 09:06, Martin Maechler <maechler at stat.math.ethz.ch>
> wrote:
>> >>>>> David Hugh-Jones <davidhughjones at gmail.com>
    >> >>>>>     on Tue, 14 Mar 2017 02:46:35 +0000 writes:
    >> >>>>> David Hugh-Jones <davidhughjones at gmail.com>
    >> >>>>>     on Tue, 14 Mar 2017 02:46:35 +0000 writes:
    >> 
    >> > Hi,
    >> > Cross-posted from SO:
    >> >
    >> http://stackoverflow.com/questions/42776058/extending-an-s3-generic-from-an-optional-package
    >> 
    >> ((sent my answer there as well))
    >> 
    >> > I have a package which provides an as.FlexTable method for its
    >> objects,
    >> > extending the S3 generic from the ReporteRs package. So, my
    >> NAMESPACE file,
    >> > generated by roxygen, has lines:
    >> 
    >> > importFrom(ReporteRs,as.FlexTable)
    >> > ...
    >> > S3method(as.FlexTable,huxtable)
    >> > ...
    >> > export(as.FlexTable)
    >> 
    >> > I don't much want to put ReporteRs in Imports: in the DESCRIPTION
    >> file,
    >> > because it involves a big external dependency on Java. But, when I
    >> put it
    >> > into Suggests:, R CMD check gives me errors like "Namespace
    >> dependency not
    >> > required".
    >> 
    >> > Is there anyway I can extend the generic without making a hard
    >> dependency?
    >> 
    >> No.  Importing is a hard dependency..
    >> Some people do not import formally but use  '<pkgNamespace>::<obj>'
    >> instead, *and* conditionalize their code on the availability of
    >> that namespace.
    >> I don't recommend that at all, and particularly not for
    >> extending a generic.
    >> 
    >> I recommend you talk with the maintainer of 'ReporteRs':
    >> 1) You could use a common (yet-to-create) very small package say
    >> 'flexS3generics'
    >> which provides S3 generics (and S4 if ..) you want to use
    >> both, and then both you and her/him import from that mini package.
    >> You'd be both authors of that package.
    >> 
    >> 2) If your package is much smaller (in its footprint, incl
    >> dependencies) than 'ReporteRs' she/he may agree to import the
    >> S3 generic from your package instead of the other way around.
    >> 
    >> Both are clean solutions,
    >> and both need some time-coordination when releasing to CRAN,
    >> '1)' being easier: Once the 'flexS3generics' is released to
    >> CRAN, change (both) your package(s) to
    >> importFrom(flexS3generics,*) but these changes and CRAN
    >> submissions are then independent of each other.
    >> 
    >> 
    >> > Cheers,
    >> > David
    >> 
    >> --
    > Sent from Gmail Mobile

    > [[alternative HTML version deleted]]
David Hugh-Jones
# 
Hi Martin,

Thanks. I figured that out after trying it myself, so I didn't do that.
OTOH, a whole new package just so I can extend a method... I feel that life
is too short. So, I cut the Gordian knot and just wrote as_FlexTable
instead of as.FlexTable, and skipped the whole inheritance issue.

Cheers,

David


On 14 March 2017 at 16:35, Martin Maechler <maechler at stat.math.ethz.ch>
wrote: