Skip to content

[Bioc-devel] Biobase/IRanges annotation maksing

8 messages · Laurent Gatto, Wolfgang Huber, Martin Morgan +1 more

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

Illustrative code and sessionInfo are given below.

I hope that I am not missing anything obvious here.

Thank you in advance.

Laurent


-- R code ---------------------------------------
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)'.
[1] "hgu95av2"
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
Error in function (classes, fdef, mtable)  : 
  unable to find an inherited method for function "annotation", for signature 
"AffyBatch"
[1] "hgu95av2"
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
#
Laurent Gatto <l.gatto at dnavision.be> writes:
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

  
    
#
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 "common 
sense" be not opposed to each other.

Best wishes
      Wolfgang

----------------------------------------------------
Wolfgang Huber, EMBL-EBI, http://www.ebi.ac.uk/huber
Martin Morgan wrote:
#
Hi,

I seem to observe to observe an odd side effect of the ":::" operator. 
Can anyone reproduce this?
	Best wishes	
	Wolfgang


library("IRanges")
annotation
showMethods("annotation")
Biobase:::annotation
showMethods("annotation")




 > library("IRanges")

Attaching package: 'IRanges'


	The following object(s) are masked from package:base :

	 cbind,
	 order,
	 pmax,
	 pmax.int,
	 pmin,
	 pmin.int,
	 rbind,
	 rep.int,
	 table

 > annotation
standardGeneric for "annotation" defined from package "IRanges"

function (x, ...)
standardGeneric("annotation")
<environment: 0x26b8da0>
Methods may be defined for arguments: x
Use  showMethods("annotation")  for currently available ones.

 > showMethods("annotation")
Function: annotation (package IRanges)
x="AnnotatedList"

 > Biobase:::annotation
standardGeneric for "annotation" defined from package "Biobase"

function (object)
standardGeneric("annotation")
<environment: 0x2920538>
Methods may be defined for arguments: object
Use  showMethods("annotation")  for currently available ones.

 > showMethods("annotation")

Function "annotation":
  <not a generic function>

 > sessionInfo()
R version 2.9.0 Under development (unstable) (2009-02-18 r47956)
x86_64-unknown-linux-gnu

locale:
LC_CTYPE=C;LC_NUMERIC=C;LC_TIME=C;LC_COLLATE=C;LC_MONETARY=C;LC_MESSAGES=en_GB.UTF-8;LC_PAPER=C;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=C;LC_IDENTIFICATION=C

attached base packages:
[1] stats     graphics  grDevices datasets  utils     methods   base

other attached packages:
[1] IRanges_1.1.38 fortunes_1.3-6

loaded via a namespace (and not attached):
[1] Biobase_2.3.10
Martin Morgan wrote:

  
    
#
Hello,

I can reproduce the behaviour on my side. 
Below is the output for today's R-devel version (2009-02-18 r47956). The same 
was observed with R-devel (2009-02-12 r47911).

Laurent
Attaching package: 'IRanges'


	The following object(s) are masked from package:base :

	 cbind,
	 order,
	 pmax,
	 pmax.int,
	 pmin,
	 pmin.int,
	 rbind,
	 rep.int,
	 table
standardGeneric for "annotation" defined from package "IRanges"

function (x, ...) 
standardGeneric("annotation")
<environment: 0x8d17d7c>
Methods may be defined for arguments: x
Use  showMethods("annotation")  for currently available ones.
Function: annotation (package IRanges)
x="AnnotatedList"
standardGeneric for "annotation" defined from package "Biobase"

function (object) 
standardGeneric("annotation")
<environment: 0x8a8eba0>
Methods may be defined for arguments: object
Use  showMethods("annotation")  for currently available ones.
Function "annotation":
 <not a generic function>
R version 2.9.0 Under development (unstable) (2009-02-18 r47956) 
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

loaded via a namespace (and not attached):
[1] Biobase_2.3.10
#
Wolfgang Huber <huber at ebi.ac.uk> writes:
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

  
    
#
Hi Martin

the re-use of the Biobase::annotation generic by GSEABase and affyPLM is 
great, because it makes it easier for users to discover and use these 
functionalities provided from the different packages (compared to them 
being separate regular functions).

You are right that the name masking issue is technically independent of 
whether you are dealing with an S4 generic or a regular function. 
However, anecdotal evidence I've seen seems to indicate that package 
developers more readily tend to use generic (in the ordinary sense of 
the word) names for S4-generic functions, which increases the frequency 
of masking events. As you say, those can easily be addressed on the 
package development level by using namespace tools, but are quite a pain 
for the end-user whose is writing scripts.

The two questions that I had in mind (sorry that they were not expressed 
that clearly) regarding what we should consider "best practice" in this 
community:

- Should you export common names like, say, "annotation", "normalize", 
"coef" for your package's functions even though you're aware of them 
being exported, with different bindings, from other packages that users 
may concurrently attach?

- What is the threshold at which it makes sense to switch from defining 
a regular function to making it a generic + 1 method? (From your 
arguments below one might conclude that one should always do the second?)

Best wishes
      Wolfgang



----------------------------------------------------
Wolfgang Huber, EMBL-EBI, http://www.ebi.ac.uk/huber
Martin Morgan wrote: