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

Benjamin Hofner benjamin.hofner at fau.de
Tue Sep 1 15:53:48 CEST 2015


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>> 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>> 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>>>
>     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>
>      >>     Fax: +49-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>>
>      >>
>      >> 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>>
>      >>     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> 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
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



More information about the R-package-devel mailing list