Skip to content

What should become of the 15 plotly...() twins now that plotHover() exists? #502

Description

@gustavdelius

There are 15 plotly…() functions (plotlyBiomass, plotlyYield, plotlySpectra, …). Each has an identical three-line body:

argg <- as.list(environment())
plotHover(do.call("plotBiomass", argg), ...)

Meanwhile plotHover() is exported and does the same job for any plot, and the array plot() methods are documented as using plotHover() rather than having plotly… twins. So the interactive story is told two ways depending on which function you started from.

This is a question rather than a proposal — I do not know how much these are used, and they are pleasant, discoverable names. Options as I see them:

  1. Leave them alone; they cost documentation but nothing else.
  2. Keep them but document them as sugar for plotHover(), so the skills and vignettes only have to teach one mechanism.
  3. Soft-deprecate in favour of plotHover().

I'd lean to (2) unless you know they are little used. Raising it because they are a visible chunk of the API surface that the analyse-and-plot documentation has to account for, and the cost is entirely in explanation rather than in maintenance.

One thing I checked while looking at these: plotlyYield declares sim2 with no default while plotYield has sim2 = NULL, which looks like it should break the single-simulation call. It does not — as.list(environment()) passes the missing argument through untouched and plotlyYield(NS_sim) returns a plotly object normally. Noting it so nobody else goes down that path.

Found while auditing the plotting API for surface the skills have to document.

Metadata

Metadata

Assignees

No one assigned

    Labels

    discussionAn idea that needs discussion before becoming a proposalplotsIssue relates to plotting functionalityquestion

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions