[R-pkg-devel] Redefinition of generic for plot function breaks plot.formula

Kevin Ushey kevinushey at gmail.com
Tue Sep 1 19:18:25 CEST 2015


FWIW, it's a very _very_ bad idea to add methods to S3 generics for
classes you don't 'own'. Some code might be written with the
expectation that `plot(df)` actually does dispatch to `plot.default`.
This implies that simply loading your package would break code in
surprising ways.

I would strongly suggest creating your own class and using
pre-existing generics whenever possible.


On Tue, Sep 1, 2015 at 9:01 AM, Benjamin Hofner <benjamin.hofner at fau.de> wrote:
> Dear Gavin,
>
> you and Hadley seem to be right. It looks like a problem which is buried
> deeper within R and the method dispatch. It seems like I have to reintroduce
> the class labeled.data.frame and plot.labeled.data.frame.
>
> However, I will post on R-devel to try to understand this issue.
>
> Thanks a lot!
> Benjamin
>
> Am 01.09.2015 um 17:54 schrieb Gavin Simpson:
>>
>> It's not just plot.formula that is broken; plot.lm is dead too for
>> example. It's seems that just unexported methods fail to be called. This
>> works plot(ts(1:100)), correctly calling the plot.ts method.
>>
>> What you must be doing overwriting the plot generic seems to be
>> clobbering S3 dispatch or killing the registration of those methods such
>> that they never get called.
>>
>> I think you might need to take this to R Devel to ask what is happening
>> to S3 dispatch when you modify the generic (by providing your own),
>> unless someone else here knows what is going on?
>>
>> If this isn't a problem in R, it looks like it would be easier all round
>> to follow Prof. Ripley's other advice/option and add a new class to
>> data.frame objects and provide a method for that new class...
>>
>> HTH
>>
>> G
>>
>> On 1 September 2015 at 07:53, Benjamin Hofner <benjamin.hofner at fau.de
>> <mailto:benjamin.hofner at fau.de>> wrote:
>>
>>     I am using it this way as I want to be able to plot data.frames but
>>     have a better display and more options. Thus, using plot.data.frame
>>     seems rather natural. A different function or new classes are just a
>>     work around. I do not want to use a new class as these functions
>>     should work on ANY data frame without coercion.
>>
>>     Additionally, I had the function plot.data.frame [*] in an old
>>     versions of the package and would like to keep it for backward
>>     compatibility.
>>
>>     [*] admittedly the function was plot.labeled.data.frame but I
>>     dropped the class labeled.data.frame as all my functions now work on
>>     regular data frames as well. If labels are present, these are used.
>>     If not, not.
>>
>>     Benjamin
>>
>>     Am 01.09.2015 um 15:44 schrieb Gavin Simpson:
>>
>>         ...or have an object that is a data.frame but to which you add an
>>         additional class
>>
>>         class(obj) <- c("my_df", "data.frame")
>>
>>         Then you can include plot.my_df() in your package, plus a
>>         function to
>>         create a my_df object from a data frame, and you don't have to
>> worry
>>         about all this and your objects will still work like data frames
>>
>>         G
>>
>>         On Sep 1, 2015 07:15, "Hadley Wickham" <h.wickham at gmail.com
>>         <mailto:h.wickham at gmail.com>
>>         <mailto:h.wickham at gmail.com <mailto:h.wickham at gmail.com>>> wrote:
>>
>>              Why don't you just create your own function?
>>
>>              Hadley
>>
>>              On Tue, Sep 1, 2015 at 8:08 AM, Benjamin Hofner
>>              <benjamin.hofner at fau.de <mailto:benjamin.hofner at fau.de>
>>         <mailto:benjamin.hofner at fau.de <mailto:benjamin.hofner at fau.de>>>
>>         wrote:
>>               > Dear Gavin,
>>               >
>>               > unfortunately, I cannot overwrite plot.data.frame only.
>>         If I do
>>              this I
>>               > get the following warning from R CMD check:
>>               >
>>               > * checking use of S3 registration ... WARNING
>>               > Registered S3 method from a standard package overwritten
>>         by 'papeR':
>>               > method from
>>               > plot.data.frame graphics
>>               >
>>               > The reason for this is given in the following statement
>>         by Prof.
>>              Ripley:
>>               >
>>               >> Do not replace registered S3 methods from
>>         base/recommended packages,
>>               >> something which is not allowed by the CRAN policies and
>>         will mean
>>               >> that everyone gets your method even if your namespace
>>         is unloaded.
>>               >
>>               > The route I am taking is one of the advised routes to go
>>         (see
>>               > https://github.com/hofnerb/papeR/issues/5). So I am
>>         still looking
>>              for a fix
>>               > of this issue.
>>               >
>>               > Your warning regarding the changed user experience is
>>         well noted.
>>              However, I
>>               > think (and am aware that this is my personal opinion)
>>         that a lot
>>              of users
>>               > will not miss the standard plot.data.frame method which
>>         is only
>>              well defined
>>               > for numerics anyway and not very informative in many
>>         situations.
>>              After your
>>               > comment I am thinking of adding an option to my
>>         plot.data.frame
>>              function
>>               > which allows to fall back to the original user experience.
>>               >
>>               > Thanks,
>>               > Benjamin
>>               >
>>               > Am 01.09.2015 um 04:37 schrieb Gavin Simpson:
>>               >>
>>               >> Why do you even need to take over `plot`,
>>         `plot.default`? You
>>              can just
>>               >> register/export the plot.data.frame method from our
>>         package without
>>               >> touching the generic or default method. The part of WRE
>>         that you
>>              refer
>>               >> to is about making functions that are *not* S3 methods
>>         in one of
>>              base R
>>               >> or it's packages into S3 generics. You are just providing
>> a
>>              method for
>>               >> an existing generic so you don't need to follow that
>> code.
>>               >>
>>               >> That said, it wouldn't be good form to fundamentally
>>         alter the way
>>               >> plot.data.frame worked as users might expect certain
>>         functionality.
>>               >>
>>               >> HTH
>>               >>
>>               >> G
>>               >>
>>               >> On 31 August 2015 at 04:03, Benjamin Hofner
>>              <benjamin.hofner at fau.de <mailto:benjamin.hofner at fau.de>
>>         <mailto:benjamin.hofner at fau.de <mailto:benjamin.hofner at fau.de>>
>>               >> <mailto:benjamin.hofner at fau.de
>>         <mailto:benjamin.hofner at fau.de> <mailto:benjamin.hofner at fau.de
>>         <mailto:benjamin.hofner at fau.de>>>>
>>
>>              wrote:
>>               >>
>>               >>     Dear all,
>>               >>
>>               >>     CRAN policies do not allow that single methods (for
>>         generic
>>               >>     functions) which are defined in base or recommended
>>         packages are
>>               >>     replaced. They advice package authors to replace
>>         the standard
>>               >>     generic and use a xxx.default method which then
>>         calls the
>>              original
>>               >>     standard generic.
>>               >>
>>               >>     Using the following code
>>               >>
>>               >>
>>               >>     ## overwrite standard generic
>>               >>     plot <- function(x, y, ...)
>>               >>          UseMethod("plot")
>>               >>
>>               >>     ## per default fall back to standard generic
>>               >>     plot.default <- function(x, y, ...)
>>               >>          graphics::plot(x, y, ...)
>>               >>
>>               >>     ## now specify modified plot function for data frames
>>               >>     plot.data.frame <- function(x, variables =
>>         names(x), ...)
>>               >>
>>               >>
>>               >>     essentially works for all tested plot.xxx
>>         functions. Yet, it
>>              breaks
>>               >>     plot.formula. How can I proceed to overwrite
>>         plot.data.frame
>>              without
>>               >>     breaking plot.formula. Any help is greatly
>> appreciated.
>>               >>
>>               >>     For a detailed description of the problem with syntax
>>              highlighting
>>               >>     and code to reproduce the problem please see:
>>               >>
>>               >>
>>               >>
>>
>> http://stackoverflow.com/questions/32246361/redefinition-of-generic-for-plot-function-breaks-plot-formula
>>               >>
>>               >>     Best,
>>               >>     Benjamin
>>               >>     --
>>               >>
>>               >>
>>
>>
>> ******************************************************************************
>>               >>     Dr. rer. nat. Benjamin Hofner
>>               >>
>>               >>     Institut für Medizininformatik, Biometrie und
>>         Epidemiologie
>>               >>     Friedrich-Alexander-Universität Erlangen-Nürnberg
>>               >>     Waldstr. 6 - 91054 Erlangen - Germany
>>               >>
>>               >>     Tel: +49-9131-85-22707 <tel:%2B49-9131-85-22707>
>>         <tel:%2B49-9131-85-22707>
>>              <tel:%2B49-9131-85-22707>
>>               >>     Fax: +49-9131-85-25740 <tel:%2B49-9131-85-25740>
>>         <tel:%2B49-9131-85-25740>
>>              <tel:%2B49-9131-85-25740>
>>               >>
>>               >>     Büro:
>>               >>        Raum 3.036
>>               >>        Universitätsstraße 22
>>               >>        (Eingang linke Seite des Gebäudes; Wegweiser IMBE)
>>               >>
>>               >> benjamin.hofner at fau.de <mailto:benjamin.hofner at fau.de>
>>         <mailto:benjamin.hofner at fau.de <mailto:benjamin.hofner at fau.de>>
>>              <mailto:benjamin.hofner at fau.de
>>         <mailto:benjamin.hofner at fau.de> <mailto:benjamin.hofner at fau.de
>>         <mailto:benjamin.hofner at fau.de>>>
>>               >>
>>               >>
>>         http://www.imbe.med.uni-erlangen.de/cms/benjamin_hofner.html
>>               >> http://www.benjaminhofner.de
>>               >>
>>               >>     ______________________________________________
>>               >> R-package-devel at r-project.org
>>         <mailto:R-package-devel at r-project.org>
>>              <mailto:R-package-devel at r-project.org
>>         <mailto:R-package-devel at r-project.org>>
>>              <mailto:R-package-devel at r-project.org
>>         <mailto:R-package-devel at r-project.org>
>>              <mailto:R-package-devel at r-project.org
>>         <mailto:R-package-devel at r-project.org>>>
>>               >>     mailing list
>>               >> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>               >>
>>               >>
>>               >>
>>               >>
>>               >> --
>>               >> Gavin Simpson, PhD
>>               >
>>               >
>>               > ______________________________________________
>>               > R-package-devel at r-project.org
>>         <mailto:R-package-devel at r-project.org>
>>              <mailto:R-package-devel at r-project.org
>>         <mailto:R-package-devel at r-project.org>> mailing list
>>               > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>
>>
>>
>>              --
>>         http://had.co.nz/
>>
>>
>>     --
>>
>> ******************************************************************************
>>     Dr. rer. nat. Benjamin Hofner
>>
>>     Institut für Medizininformatik, Biometrie und Epidemiologie
>>     Friedrich-Alexander-Universität Erlangen-Nürnberg
>>     Waldstr. 6 - 91054 Erlangen - Germany
>>
>>     Tel: +49-9131-85-22707 <tel:%2B49-9131-85-22707>
>>     Fax: +49-9131-85-25740 <tel:%2B49-9131-85-25740>
>>
>>     Büro:
>>        Raum 3.036
>>        Universitätsstraße 22
>>        (Eingang linke Seite des Gebäudes; Wegweiser IMBE)
>>
>>     benjamin.hofner at fau.de <mailto:benjamin.hofner at fau.de>
>>
>>     http://www.imbe.med.uni-erlangen.de/cms/benjamin_hofner.html
>>     http://www.benjaminhofner.de
>>
>> ******************************************************************************
>>
>>
>>
>>
>> --
>> Gavin Simpson, PhD
>
>
> --
> ******************************************************************************
> Dr. rer. nat. Benjamin Hofner
>
> Institut für Medizininformatik, Biometrie und Epidemiologie
> Friedrich-Alexander-Universität Erlangen-Nürnberg
> Waldstr. 6 - 91054 Erlangen - Germany
>
> Tel: +49-9131-85-22707
> Fax: +49-9131-85-25740
>
> Büro:
>   Raum 3.036
>   Universitätsstraße 22
>   (Eingang linke Seite des Gebäudes; Wegweiser IMBE)
>
> benjamin.hofner at fau.de
>
> http://www.imbe.med.uni-erlangen.de/cms/benjamin_hofner.html
> http://www.benjaminhofner.de
>
> ______________________________________________
> R-package-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel



More information about the R-package-devel mailing list