[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
data.frame).
* 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.
Martin
> "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:
>>> LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=en_US.UTF-8;LC_COLLATE=en_US.UTF-8;LC_MONETARY=C;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US.UTF-8;LC_IDENTIFICATION=C
>>>
>>> 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