Creating S3 methods for S4 classes (coming from r-package-devel)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Creating S3 methods for S4 classes (coming from r-package-devel)

Joris FA Meys
 Dear all,

I asked this question on r-package-devel but Martin Maechler pointed out
this was more suited on R-devel. So here it goes:

per the manual, one should create and register both the S3 and a S4 method
if one needs a method for an S4 class for a function using S3 dispatching.
This is cumbersome, and not very optimal.

I was wondering if there's a better way to do this. Currently I recreate a
generic in my package and create a default method that sends all the other
classes to the S3 generic, eg:

setGeneric("predict")
setMethod("predict", "ANY", stats::predict)

I'm not sure if this hasn't any adverse consequences, as it is not the
recommended approach.

It would be great if these generics could be made available through stats4.
If this would be the prefered route, I volunteer to create the patch for
that.

Any thoughts?
Cheers
Joris

(Original mail on r-package-devel :
https://stat.ethz.ch/pipermail/r-package-devel/2018q2/002757.html )


--
Joris Meys
Statistical consultant

Department of Data Analysis and Mathematical Modelling
Ghent University
Coupure Links 653, B-9000 Gent (Belgium)
<https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium&entry=gmail&source=g>

-----------
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/

-------------------------------
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Creating S3 methods for S4 classes (coming from r-package-devel)

Michael Lawrence-3
You only have to make an S4 method if there is already an S4 generic.
If there is just an S3 generic, then just define S3 methods on it. I
think we should stay away from defining S4 generics when there is no
good reason for them. Good reasons include multiple dispatch, or a
non-default signature. Neither of those apply in this case.

Michael

On Thu, May 24, 2018 at 6:39 AM, Joris Meys <[hidden email]> wrote:

>  Dear all,
>
> I asked this question on r-package-devel but Martin Maechler pointed out
> this was more suited on R-devel. So here it goes:
>
> per the manual, one should create and register both the S3 and a S4 method
> if one needs a method for an S4 class for a function using S3 dispatching.
> This is cumbersome, and not very optimal.
>
> I was wondering if there's a better way to do this. Currently I recreate a
> generic in my package and create a default method that sends all the other
> classes to the S3 generic, eg:
>
> setGeneric("predict")
> setMethod("predict", "ANY", stats::predict)
>
> I'm not sure if this hasn't any adverse consequences, as it is not the
> recommended approach.
>
> It would be great if these generics could be made available through stats4.
> If this would be the prefered route, I volunteer to create the patch for
> that.
>
> Any thoughts?
> Cheers
> Joris
>
> (Original mail on r-package-devel :
> https://stat.ethz.ch/pipermail/r-package-devel/2018q2/002757.html )
>
>
> --
> Joris Meys
> Statistical consultant
>
> Department of Data Analysis and Mathematical Modelling
> Ghent University
> Coupure Links 653, B-9000 Gent (Belgium)
> <https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium&entry=gmail&source=g>
>
> -----------
> Biowiskundedagen 2017-2018
> http://www.biowiskundedagen.ugent.be/
>
> -------------------------------
> Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
>
>         [[alternative HTML version deleted]]
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Creating S3 methods for S4 classes (coming from r-package-devel)

Joris FA Meys
On Thu, May 24, 2018 at 6:20 PM, Michael Lawrence <[hidden email]
> wrote:

> You only have to make an S4 method if there is already an S4 generic.
> If there is just an S3 generic, then just define S3 methods on it.


I was refering to the recommendations in ?Methods_for_S3 (
https://stat.ethz.ch/R-manual/R-devel/library/methods/html/Methods_for_S3.html).
:

"Two possible mechanisms for implementing a method corresponding to an S4
class, there are two possibilities are to register it as an S3 method with
the S4 class name or to define and set an S4 method, which will have the
side effect of creating an S4 generic version of this function.

For most situations either works, but the recommended approach is to do
both:"

The reasoning is described there as well, and I have no reason to believe
that information is not up to date. I can get away with defining an S3
generic, but this stops being useful when using superclasses for reasons
mentioned in the documentation.

I
> think we should stay away from defining S4 generics when there is no
> good reason for them. Good reasons include multiple dispatch, or a
> non-default signature. Neither of those apply in this case.
>

I would personally prefer to use dispatching that's tailored to the type of
class I work with, as that seems more consistent. But I agree we should
avoid defining generics for the same function in different packages, hence
my proposal about stats4.


--
Joris Meys
Statistical consultant

Department of Data Analysis and Mathematical Modelling
Ghent University
Coupure Links 653, B-9000 Gent (Belgium)
<https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium&entry=gmail&source=g>

-----------
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/

-------------------------------
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Creating S3 methods for S4 classes (coming from r-package-devel)

Michael Lawrence-3
On Thu, May 24, 2018 at 10:47 AM, Joris Meys <[hidden email]> wrote:

>
>
> On Thu, May 24, 2018 at 6:20 PM, Michael Lawrence
> <[hidden email]> wrote:
>>
>> You only have to make an S4 method if there is already an S4 generic.
>> If there is just an S3 generic, then just define S3 methods on it.
>
>
> I was refering to the recommendations in ?Methods_for_S3
> (https://stat.ethz.ch/R-manual/R-devel/library/methods/html/Methods_for_S3.html).
> :
>
> "Two possible mechanisms for implementing a method corresponding to an S4
> class, there are two possibilities are to register it as an S3 method with
> the S4 class name or to define and set an S4 method, which will have the
> side effect of creating an S4 generic version of this function.
>
> For most situations either works, but the recommended approach is to do
> both:"
>
> The reasoning is described there as well, and I have no reason to believe
> that information is not up to date. I can get away with defining an S3
> generic, but this stops being useful when using superclasses for reasons
> mentioned in the documentation.
>

The reason for having an S4 method is that if there is an S4 generic,
an S4 method (potentially on a superclass) will take precedence. But
if there is no S4 generic, then there are no S4 methods.

It is possible for another package to create an S4 generic. In that
case it would be defensive to define another generic locally. If they
use the same implicit generic, then it should be merged with the local
generic, and things should work. But that is assuming a lot. It would
be preferable for no package to define an S4 generic for predict(),
since there is no reason for it, and it only complicates things.

>
>> I
>> think we should stay away from defining S4 generics when there is no
>> good reason for them. Good reasons include multiple dispatch, or a
>> non-default signature. Neither of those apply in this case.
>
>
> I would personally prefer to use dispatching that's tailored to the type of
> class I work with, as that seems more consistent. But I agree we should
> avoid defining generics for the same function in different packages, hence
> my proposal about stats4.
>

Single dispatch should be consistent between S3 and S4. I think we
should keep things simple and just have one generic, the one we
already have.

>
> --
> Joris Meys
> Statistical consultant
>
> Department of Data Analysis and Mathematical Modelling
> Ghent University
> Coupure Links 653, B-9000 Gent (Belgium)
>
> -----------
> Biowiskundedagen 2017-2018
> http://www.biowiskundedagen.ugent.be/
>
> -------------------------------
> Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel