[Bioc-devel] annotation() to BiocGenerics?

[Robert Castelo]

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.