[Bioc-devel] Problem with generic methods name conflicts

[Stephanie M. Gogarten]

If a package is listed in "Depends", should it also be listed in 
"Imports"?  I initially thought that this was redundant, and assumed 
that any package in Depends should be imported (unless it does not have 
a namespace).  However, I tried to import a package (sandwich) which did 
not follow that rule - it depended on zoo but did not import it, thus 
forcing me to depend on it in order to use its functions within my own 
package (see recent discussion on R-devel).  It seems to me that the 
best solution is to avoid listing packages twice in the DESCRIPTION 
file, and to import anything in "Depends" unless there is some very good 
reason not to.  But if the convention is to explicitly list all imports 
in the "Imports" field, I will follow that.

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
>
>