[Bioc-devel] Problem with generic methods name conflicts

[Martin Morgan]

On 10/13/2011 12:21 PM, Stephanie M. Gogarten wrote:
>
>>
>> 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.
>>
>
> Thanks for the clear explanations - I will endeavor to use importFrom()
> more often.
>
>> 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)
>
> The "Writing R Extensions" manual declares:
> "Packages declared in the ‘Depends’ field should not also be in the
> ‘Imports’ field."

Probably you're right and we should tow more closely to the party line.

> A related question - previously a reason to use Depends was for packages
> without a namespace. But since R 2.14 creates namespaces for everything,
> does that mean it is now safe to use Imports for these packages?

I think its a strong stick to make developers use name spaces, and to 
the extent that it is successful, then yes Imports becomes a much more 
consistently preferred option. For your sandwich example, though, the 
imposed name space doesn't importFrom(zoo, ...)

 > names(getNamespaceImports("sandwich"))
[1] "base"  "stats"

so you're still in trouble.

Martin

> Stephanie
>
>
>>
>> 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
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Bioc-devel at r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>
>>


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

Location: M1-B861
Telephone: 206 667-2793