[Bioc-devel] annotation() to BiocGenerics?
hi Martin,
On 09/21/2012 06:54 PM, Martin Morgan wrote:
On 09/21/2012 09:26 AM, Robert Castelo wrote:
hi Martin, On 09/21/2012 05:59 PM, Martin Morgan wrote:
On 09/21/2012 05:05 AM, Benilton Carvalho wrote:
Replace Biobase::`annotation<-`(eScoEset, "") by Biobase::`annotation<-`(eScoEset, value="")
why not just annotation(eScoEset) <- "" with importFrom(Biobase, "annotation<-") in the NAMESPACE?
well, my understanding of the general policy to use classes and methods defined in other packages is that i should *always* "import" them in the NAMESPACE file. however, somehow i feel more comfortable using this pkg::f() idiom when i call something defined somewhere else because just reading the code i know immediately where imported things come from. is there any reason related to performance, correctness or coding style by which you think i should not do it?
I was more struck by this usage eScoEset <- Biobase::`annotation<-`(eScoEset, "") which I would have written, if following your preferred style, Biobase::annotation(eScoEset) <- "" (I personally would have written annotation(eScoEset) <- "").
yes, you're right, but at the time i wrote this code, about year and a half ago -BioC 2.7-, those assignments (Biobase::exprs() <- x or Biobase::annotation() <- x) were not working, i was getting an error and found that syntatic workaround. now i changed into what you suggest (which is indeed much easier to read and write) and it works, so i just committed this subtle change.
There is a performance difference (:: is a function call, and there are several symbol look-ups involved) but I doubt that would be a serious concern in a seldom-used function (different, though if this were called in a large loop). There is a subtle issue relevant to S4, though the implementation of annotation<- shields you from this -- note how the following changes the value of 'b' as well as 'a'
> setClass("A", representation(value="numeric"))
> a <- b <- new("A", value=1)
> `slot<-`(a, "value", value=2)
An object of class "A" Slot "value": [1] 2
> b
An object of class "A" Slot "value": [1] 2 which does not occur for slot(a, "value") <- 2 For what it's worth, the reason for your code breakage is that the signature of annotation<- changed from function(object, value) to function(object, ..., value). This is desirable because it allows methods to define additional arguments to the replacement function, and does not break the replacement method when used as annotation(eScoEset) <- "" (replacement methods match the right hand side to the last argument) but obviously caused problems for your approach.
thanks for the clarification, i didn't know about this rightmost rule on replacement methods. robert.