[Bioc-devel] Biobase/IRanges annotation maksing

Martin Morgan mtmorgan at fhcrc.org
Thu Feb 19 16:29:27 CET 2009

Wolfgang Huber <huber at ebi.ac.uk> writes:

> Hi
> of course there is no fundamental reason why the same name should not
> be used for different things in different packages, and in many
> instances this is the most reasonable solution. However, I think the
> user-friendliness of the set of Bioconductor packages would be
> improved if authors tried to keep such instances to a minimum.
> Since there is considerable overlap and collaboration between the
> authors of Biobase and IRange I am optimistic that a (perhaps less
> modular but) more integrated solution could be found.
> Currently, the generic function Biobase::annotation has exactly one
> method, for signature "eSet", and the generic function
> IRanges::annotation has exactly one method, for signature
> "AnnotatedList". I.e. although they are generic functions in the
> S4-technical sense, neither is generic in the common sense of the
> word. I think it could be a goal for us that the concepts "S4" and

Hi Wolfgang --

Not exactly sure what you're getting at here (which doesn't bode well
for common sense on my part, I guess); I read this as saying these
functions might be 'regular', and not generic at all. But as you know

* Methods are not restricted to definition in the package of the
generic. So there are two methods on Biobase::annotation after
library(GSEABase), three after library(affyPLM), etc.

* Generics provide type checking that is useful even when there is a
single method (e.g., Biobase::annotation does not operate on, say, a

* Generics help to define an API (e.g., Biobase::annotation's single
method operates on 4 different classes defined in Biobase). The API
can be discovered programmatically, modulo the quirks of showMethod
(the 'where' argument can be useful under the current regime).

* Two identically named regular functions would conflict in the same
way, except perhaps without notifying the user.

Also worth reiterating that the example I mentioned pointed to a bug
(relying on user search path for function discovery) that has been
resolved through use of a name space and 'imports'. 

End users still have to contend with the competing functions (using
Biobase::annotation to disambiguate). This is unfortunate and perhaps
amenable to common sense, but independent of S4 / generics.


> "common sense" be not opposed to each other.
> Best wishes
>       Wolfgang
> ----------------------------------------------------
> Wolfgang Huber, EMBL-EBI, http://www.ebi.ac.uk/huber
> Martin Morgan wrote:
>> Laurent Gatto <l.gatto at dnavision.be> writes:
>>> Dear Bioc developeRs,
>>> I noted recently that Biobase's 'annotation' and 'annotation<-'
>>> objects are masked by IRanges. Now calling annotation(AffyBatch),
>>> of annotation(ExpressionSet) throws an 'unable to find an inherited
>>> method for function "annotation", for signature "AffyBatch"' error.
>>> Some of my functions fail because they rely on functions that call
>>> annotation(AffyBatch). 
>>> My questions are (1) is this the expected behaviour and if yes (2)
>>> how am I and/or upstream maintainers supposed to elegantly deal
>>> with it?
>> Hi Laurent -- I just came across this issue myself -- package A
>> failed
>> because it called a function in package B which had a dependency on
>> package C which, due to changes in package D, now attached IRanges to
>> the search path. Package B then found IRange::annotation on the search
>> path, instead of Biobase::annotation.
>> The solution was easy, in the end -- add
>>   importMethodsFrom(Biobase, annotation)
>> to the NAMESPACE of package B, and move Biobase from 'Depends:' to
>> 'Imports:' in package B, which is definitely the Right Thing To Do. It
>> doesn't matter now that IRanges is on the user search path, package B
>> always gets the function it wants.
>> The solution is less elegant for a function that is not in a name
>> space, e.g., because the user is writing it in the global environment,
>> as in your example below. Then the solution is to use
>>   Biobase::annotation(eset)
>> in place of annotation(eset).
>> There might be additional technical solutions that Biobase / IRanges
>> /
>> Biostrings package authors can explore for this particular case...
>> Martin
>>> Illustrative code and sessionInfo are given below.
>>> I hope that I am not missing anything obvious here.
>>> Thank you in advance.
>>> Laurent
>>> -- R code ---------------------------------------
>>>> source("http://bioconductor.org/biocLite.R")
>>>> update.packages(rep=biocinstallRepos(), ask=FALSE)
>>>> library(affydata)
>>> Loading required package: affy
>>> Loading required package: Biobase
>>> Welcome to Bioconductor
>>>   Vignettes contain introductory material. To view, type
>>>   'openVignette()'. To cite Bioconductor, see
>>>   'citation("Biobase")' and for packages 'citation(pkgname)'.
>>>> data(Dilution)
>>>> annotation(Dilution)
>>> [1] "hgu95av2"
>>>> library(IRanges)
>>> Attaching package: 'IRanges'
>>> 	The following object(s) are masked from package:Biobase :
>>> 	 annotation,
>>> 	 annotation<- 
>>> 	The following object(s) are masked from package:base :
>>> 	 cbind,
>>> 	 order,
>>> 	 pmax,
>>> 	 pmax.int,
>>> 	 pmin,
>>> 	 pmin.int,
>>> 	 rbind,
>>> 	 rep.int,
>>> 	 table 
>>>> annotation(Dilution)
>>> Error in function (classes, fdef, mtable)  :   unable to find an
>>> inherited method for function "annotation", for signature
>>> "AffyBatch"
>>>> Biobase:::annotation(Dilution)
>>> [1] "hgu95av2"
>>>> sessionInfo()
>>> R version 2.9.0 Under development (unstable) (2009-02-12 r47911)
>>> i686-pc-linux-gnu 
>>> locale:
>>> attached base packages:
>>> [1] stats     graphics  grDevices utils     datasets  methods
>>> base     
>>> other attached packages:
>>> [1] IRanges_1.1.38  affydata_1.11.3 affy_1.21.7     Biobase_2.3.10 
>>> loaded via a namespace (and not attached):
>>> [1] affyio_1.11.3        preprocessCore_1.5.3 tools_2.9.0
>>> _______________________________________________
>>> Bioc-devel at stat.math.ethz.ch mailing list
>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel

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

Location: Arnold Building M2 B169
Phone: (206) 667-2793

More information about the Bioc-devel mailing list