[Bioc-devel] Problem with generic methods name conflicts

[Hervé Pagès]

Hi developers,

On 11-10-13 08:36 AM, Simon Anders wrote:
> Dear Kaspar and Herb
>
> On 2011-10-13 17:14, Kasper Daniel Hansen wrote:
>> Second I will note (like you have already noticed) that this is a
>> recent addition to Biobase, seemingly coming from the DEseq crowd and
>> that this particular generic is not used at all in Biobase, it just
>> contains the generic.
>>
>> The best solution to this is of course to agree with the other
>> package(s) about the signature of the generic. You are using
>> object, ...
>> which to me seems very nice. Biobase is using
>> cds, normalized=TRUE
>> To me it seems that "object" works better as the function argument of
>> a generic, and that you are right in adding the .... Also,
>> "normalized=TRUE" seems (to me) to be something that really belongs in
>> the individual method (is this really relevant for all signatures?),
>> so my suggestion would be to adapt your generic into Biobase. It
>
> I fully agree. Please change the definition in Biobase to
> "counts( object, ...)" and I'll change DESeq/DEXSeq accordingly. That
> the specialized argument 'normalized' turned up in Biobase was an
> oversight.
>
> To get back to the general discussion: It is an unfortunate property of
> CLOS and S4 that a generic function needs to be defined before one can
> define methods; other language demonstrate that this requirement is not
> needed. (Compare with overloading in C++; the reason we have it in
> CLOS/S4 is, as far as I understand it, solely that the construction
> allowed to add methods without modifying the core language.)
>
> Hence, it seems reasonable to consider the definition of a generic as a
> mere formality without semantic context. This is especially true if
> multiple dispatch is not needed, because then, the standard signature
> "object, ..." will always to the job. Hence, we could make it a policy
> that whenever two packages both wish to define methods for a generic f,
> we simply define one in Biobase (or maybe, in BiocGenerics) with always
> the same standard signature "object, ...".

That makes a lot of sense to me. That would solve the current conflict
with the updateObject() generic defined in Biobase and IRanges (both
packages are too big to depend one on each other). And I would be happy
to move other setGeneric statements currently in IRanges/GenomicRanges
/Biostrings to BiocGenerics. Some of those explicit generic definitions
just correspond to stuff defined in base R (e.g. cbind, rbind, pmin,
pmax, eval etc...), and BiocGenerics sounds like a better place to have
them.

Cheers,
H.

>
> Simon
>
> _______________________________________________
> Bioc-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel


-- 
Hervé Pagès

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpages at fhcrc.org
Phone:  (206) 667-5791
Fax:    (206) 667-1319