[R-pkg-devel] Redefinition of generic for plot function breaks plot.formula
Gavin Simpson
ucfagls at gmail.com
Tue Sep 1 17:54:51 CEST 2015
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>
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>> 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
>
> ******************************************************************************
>
--
Gavin Simpson, PhD
[[alternative HTML version deleted]]
More information about the R-package-devel
mailing list