On Mon, Apr 29, 2019 at 6:55 AM Pages Gallego, M. <
m.pagesgall...@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@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
