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:
- Leave them alone; they cost documentation but nothing else.
- Keep them but document them as sugar for
plotHover(), so the skills and vignettes only have to teach one mechanism.
- 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.
There are 15
plotly…()functions (plotlyBiomass,plotlyYield,plotlySpectra, …). Each has an identical three-line body:Meanwhile
plotHover()is exported and does the same job for any plot, and the arrayplot()methods are documented as usingplotHover()rather than havingplotly…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:
plotHover(), so the skills and vignettes only have to teach one mechanism.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-plotdocumentation has to account for, and the cost is entirely in explanation rather than in maintenance.One thing I checked while looking at these:
plotlyYielddeclaressim2with no default whileplotYieldhassim2 = NULL, which looks like it should break the single-simulation call. It does not —as.list(environment())passes the missing argument through untouched andplotlyYield(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.