[Bioc-devel] When to use generics?

Boris Steipe bor|@@@te|pe @end|ng |rom utoronto@c@
Wed May 1 19:15:27 CEST 2019

I am more and more emphasizing <package>::<function>() syntax in my teaching, to avoid the issues that library(<package>) have wrt. order of loading, and clarity of code. It's my understanding that that's a general trend. Now, do correct me if I'm wrong but IIRC,  that doesn't work well with generics because they don't get registered. If so, that might be another consideration.


> On 2019-05-01, at 12:18, Michael Lawrence via Bioc-devel <bioc-devel using r-project.org> wrote:
> This is good advice. The purpose of the software also matters. The main
> advantage of a generic is extensibility. If extensibility is important,
> generics are appropriate, even if there is no immediate need for
> polymorphism. Bioconductor emphasizes extensibility, and thus generics, but
> it's not the only goal.
> On Wed, May 1, 2019 at 8:55 AM Kasper Daniel Hansen <
> kasperdanielhansen using gmail.com> wrote:
>> This is a common situation. Most packages might have a need for something
>> that looks like a generic, but it really only has a usage inside your own
>> package(s).
>> In many ways, the pseudo-generic you define using if() statements is often
>> easier to work with, debugging wise and code-reading wise. However, there
>> is a certain beauty to generics. IME many newcomers to S4 overdo it with
>> generics. My rule of thumb is don't do a generic unless you have at least 3
>> different classes you're doing dispatch on. Well, you have 3 classes, so I
>> would start thinking about it. For better or worse, this is unlikely to
>> make much difference so you should choose the one that makes the most sense
>> to you as a writer.
>> If you go down the generic route, think hard about the name.
>> On Mon, Apr 29, 2019 at 10:38 AM Michael Lawrence via Bioc-devel <
>> bioc-devel using r-project.org> wrote:
>>> On Mon, Apr 29, 2019 at 6:55 AM Pages Gallego, M. <
>>> M.PagesGallego using umcutrecht.nl> wrote:
>>>> Dear all,
>>>> I am currently developing a package and I am a bit confused in when one
>>>> should define a generic. Let me propose an example:
>>>> Suppose I have defined 3 classes: one for proteomics data, one for
>>>> metabolomics data and one for transcriptomics data. I have a function
>>>> “foo(x)” that will do the same to any of the 3 classes, but requires a
>>>> slightly different implementation for each one. I could do something
>>> like
>>>> that:
>>>> ```
>>>> foo <- function(x) {
>>>>    if (is(x, ‘proteomics’)) {
>>>>          foo.protein(x)
>>>>    } else if (is(x, ‘metabolomics’)) {
>>>>          foo.metabo(x)
>>>>    } else if (is(x, ‘transcriptomics’)) {
>>>>          foo.trans(x)
>>>>    }
>>>> }
>>>> ```
>>>> And then define foo.protein, foo.metabo and foo.trans.
>>>> But this is basically the same as defining the generic “foo” and then
>>>> defining a method for each of the classes.
>>>> The problem is that “foo” is not generic “enough” in terms that outside
>>>> the package it has no use. Therefore, defining the generic seems like a
>>> big
>>>> responsibility in that it should have a use outside the package. Would
>>> you
>>>> still define “foo” as generic in this case?
>>> Not exactly sure what you mean, but if a function has no use outside of a
>>> package, just avoid exporting it.
>>> Are there any guidelines in when one should or should not define a
>>> generic?
>>>> From:
>>> https://www.bioconductor.org/help/course-materials/2017/Zurich/S4-classes-and-methods.html#extending-a-class-without-adding-any-slot
>>>> in section 2.2.2 it recommends to reuse existing generics (which makes a
>>>> lot of sense), but then it also says that you can define new generics
>>> for
>>>> specialized operations, what if the operation is very specialized?
>>> One recommendation is that if an operation is very specialized it should
>>> have a very special name. In the context of generics, that helps avoid
>>> conflicts.
>>> From:
>>> https://www.bioconductor.org/help/course-materials/2011/AdvancedRFeb2011Seattle/ImplementingS4Objects-lab.pdf
>>>> in section 2.3 it says that the recommended way to implement accessors
>>> is
>>>> through methods (which require generics if none exist), is this always
>>> the
>>>> case for all S4 classes?
>>>> I apologize in advance if these are very naïve questions.
>>> At the very least you'll want some level of abstraction around the object
>>> representation, even for internal classes. You could take a lazy approach,
>>> first making ordinary functions, then transforming them into generics
>>> later
>>> when it becomes necessary. For public accessors, it's hard to predict when
>>> it will become necessary, since generics are meant to be reused by others,
>>> thus it is often best to make them generic initially. It is OK for APIs to
>>> evolve over time though. In practice, once generics become generally
>>> adopted, they need to move to a more general package.
>>> Best,
>>>> Marc
>>> ------------------------------------------------------------------------------
>>>> De informatie opgenomen in dit bericht kan vertrouwelijk zijn en is
>>>> uitsluitend bestemd voor de geadresseerde. Indien u dit bericht
>>> onterecht
>>>> ontvangt, wordt u verzocht de inhoud niet te gebruiken en de afzender
>>>> direct
>>>> te informeren door het bericht te retourneren. Het Universitair Medisch
>>>> Centrum Utrecht is een publiekrechtelijke rechtspersoon in de zin van de
>>>> W.H.W.
>>>> (Wet Hoger Onderwijs en Wetenschappelijk Onderzoek) en staat
>>> geregistreerd
>>>> bij
>>>> de Kamer van Koophandel voor Midden-Nederland onder nr. 30244197.
>>>> Denk s.v.p aan het milieu voor u deze e-mail afdrukt.
>>> ------------------------------------------------------------------------------
>>>> This message may contain confidential information and ...{{dropped:22}}
>>> _______________________________________________
>>> Bioc-devel using r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
> 	[[alternative HTML version deleted]]
> _______________________________________________
> Bioc-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel

More information about the Bioc-devel mailing list