They're symbols in the namespace, so namespace qualification is possible.
On Wed, May 1, 2019 at 10:15 AM Boris Steipe <boris.ste...@utoronto.ca>
wrote:
> 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.
>
> Cheers,
> Boris
>
>
>
>
> > On 2019-05-01, at 12:18, Michael Lawrence via Bioc-devel <
> bioc-devel@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 <
> > kasperdanielhan...@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@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
>
> _______________________________________________
> 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
