[Bioc-devel] When to use generics?
Pages Gallego, M.
M@P@ge@G@||ego @end|ng |rom umcutrecht@n|
Thu May 2 16:52:20 CEST 2019
Thank you all for the discussion and input. I have decided to use generics for the
time being since I am working with 3 classes and might add a fourth one later on.
Also, worst case scenario, reverting from generics to "if statements wrapper"
functions should not be too terrible.
Many thanks,
Marc
On 01/05/2019, 19:30, "Bioc-devel on behalf of Pages, Herve" <bioc-devel-bounces using r-project.org on behalf of hpages using fredhutch.org> wrote:
Hi Boris,
AFAICT the <package>::<function>() syntax also works well with generics.
Note that people sometimes specify the <package> that exports some
specific method for the generic when they should actually specify the
<package> where the generic is defined.
One thing about the "regular function with if (is()) statements" vs
generic discussion is that it's also about control. The former is fine
as long as you control the types of object that your function handles
but it doesn't make it possible for other people to add more types.
Using a generic facilitate extensibility **by others**. Maybe you want
that, maybe you don't. But it's an important part of the equation.
H.
On 5/1/19 10:15, Boris Steipe 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 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.bioconductor.org_help_course-2Dmaterials_2017_Zurich_S4-2Dclasses-2Dand-2Dmethods.html-23extending-2Da-2Dclass-2Dwithout-2Dadding-2Dany-2Dslot&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=9kRwQI3Gm9QxfkAuhHrOp_TSf6N7A8o14by7HzBKx84&s=62ssH39aZzZD_84DE44xuvbtcCIh5Pw6ib4y2H64CfE&e=
>>>>> 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.bioconductor.org_help_course-2Dmaterials_2011_AdvancedRFeb2011Seattle_ImplementingS4Objects-2Dlab.pdf&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=9kRwQI3Gm9QxfkAuhHrOp_TSf6N7A8o14by7HzBKx84&s=9giYcaLVIXbPt8YpsF4X1-OF029NvlWG7fcQkIi8asE&e=
>>>>> 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://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=9kRwQI3Gm9QxfkAuhHrOp_TSf6N7A8o14by7HzBKx84&s=A3ww3QG1-4B3tHk_NclY57XOIpjMYnSAoKiAKgXypQg&e=
>>>>
>> [[alternative HTML version deleted]]
>>
>> _______________________________________________
>> Bioc-devel using r-project.org mailing list
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=9kRwQI3Gm9QxfkAuhHrOp_TSf6N7A8o14by7HzBKx84&s=A3ww3QG1-4B3tHk_NclY57XOIpjMYnSAoKiAKgXypQg&e=
> _______________________________________________
> Bioc-devel using r-project.org mailing list
> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=9kRwQI3Gm9QxfkAuhHrOp_TSf6N7A8o14by7HzBKx84&s=A3ww3QG1-4B3tHk_NclY57XOIpjMYnSAoKiAKgXypQg&e=
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpages using fredhutch.org
Phone: (206) 667-5791
Fax: (206) 667-1319
_______________________________________________
Bioc-devel using r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
More information about the Bioc-devel
mailing list