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@r-project.org> wrote:
> 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
>
[[alternative HTML version deleted]]
_______________________________________________
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
