[Bioc-devel] When to use generics?

[Michael Lawrence]

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]]