[Bioc-devel] Problem with generic methods name conflicts

Lesson 2: importFrom, rather than import

In terms of

 > solution is to avoid listing packages twice in the DESCRIPTION file

The starting point is to only use Imports: and importFrom, thinking
selfishly as a developer who wants to minimize exposure to the whims of
other packages and the user search path and for your user not wanting to
clutter their work space with unnecessary symbols / help functions, etc.

Lesson 3: Use Imports: rather than Depends:, unless necessary.

When is it good practice to use Depends:? An answer might be because
functions in your package return to the user objects (e.g.,
ExpressionSet) that can only be manipulated if they have access to that
package (Biobase); maybe there are similar situations.

Lesson 4: Use Depends: Foo if return objects from your function are from
package Foo.

So finally both Depends: and Imports: ? I think Depends: is sufficient,
but I'd prefer the explicit indication of intention -- not all Depends:
will be import'ed. But this is a little open to discussion

Lesson 5: Depends'ing and Imports'ing the same package is not strictly
required (Depends: is sufficient)

Martin

Stephanie

On 10/13/11 10:08 AM, bioc-devel-request at r-project.org wrote:

------------------------------

Message: 5
Date: Thu, 13 Oct 2011 09:52:45 -0700
From: Martin Morgan<mtmorgan at fhcrc.org>
To: Herb Holyst<holyst at mail.med.upenn.edu>
Cc:bioc-devel at r-project.org, Wade Rogers<rogersw at mail.med.upenn.edu>
Subject: Re: [Bioc-devel] Problem with generic methods name conflicts
Message-ID:<4E97175D.1060001 at fhcrc.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 10/13/2011 08:04 AM, Herb Holyst wrote:

Hi,

I am hoping someone can point me in the right direction. I received

a courtesy message from the Marc Carlson the our package flowFP had
compilation errors, and after a bit of poking I discovered the
Biobase added a new generic method called 'counts' which we had
previously defined in flowFP. Since our package depends on Biobase we
have a name collision.

Here is the definition of our 'counts' generic out of flowFP's

AllGenerics.R file:

##

=========================================================================

## counts Methods.
## - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

- - - - -

if (!isGeneric("counts")) {
setGeneric("counts", function(object, ...) standardGeneric("counts"))
}

I think that this construct pre-dates name spaces; it's weird (to me) to
define a method on a generic that one doesn't know about, e.g., maybe
'counts' is documented to return a vector of European nobleman. It also
implies that 'counts' is found on the user search path rather than in
the package name space, so sometimes the intended counts is found,
sometimes not.

These days I think that one would importFrom(Biobase, counts) and then
setMethod on the known generic (if Biobase has an appropriate counts
generic) or create a new generic (which I think would not normally be
the case).

A secondary question that quickly comes up is how to make the user aware
of the generic 'counts'.

On the one hand (I think this is the usual solution) it might be
appropriate to (in the DESCRIPTION file)

Depends: Biobase
Imports: Biobase

and (in the NAMESPACE file)

importFrom(Biobase, counts)
exportMethods(counts)

which arranges for the counts generic from Biobase to be available to
you for attaching methods, and to the user via the standard search path,
and for the methods defined in your package to be associated with that
generic.

On a second hand one might think that, while your package has a use for
some-of-Biobase, the user does not have a use for all-of-Biobase so

Imports: Biobase

and

importFrom(Biobase, counts)
export(counts)

which allows you to add your methods to Biobase::counts, then passes
Biobase::counts through to be visible to the user. This seems awkward;
it requires that you document the 'counts' generic (you're the one
making it available to the user) even though the generic is in Biobase.
The motivation for not attaching Biobase to the search path is probably
part of the motivation for a BiocGenerics class -- too much clutter for
the user.

On the third hand one might forgo Biobase entirely (neither Depends: nor
Imports:), define a generic counts in your own package and export that.
Let the user disambiguate if they happen to load Biobase in addition to
your package. For disparate data types and questions this might be
appropriate, but for data types shared by different packages it
unfortunately leads to a multiplication of classes and a confusion of
interfaces.

On the fourth hand, perhaps your package has a use for some of Biobase
but the user does not. So Imports: and importFrom, with no exports.

There are likely to be other hands.

Martin