[Rd] [patch] add=TRUE in plot.default()

[Duncan Murdoch]

On 3/9/2008 5:58 PM, Andrew Clausen wrote:
> On Sun, Mar 09, 2008 at 04:04:08PM -0400, Duncan Murdoch wrote:
>> Part of the reason I didn't like your patch is that it was incomplete: 
>> it didn't patch the plot.default.Rd file.
> 
> Fair enough -- I wasn't sure whether I was fixing a bug or not.  ("..."
> spreads the documentation around a bit.)
> 
>> That function already has 
>> around 16 parameters; do we really want to add another one, that 
>> interacts with some of the ones that are there?
> 
> Yes.  The ability to plot things on top of each other is important.
> The simplicity created by having a single interface for adding to plots
> outweighs the complexity of yet another parameter.
> 
> The add parameter only interacts with other parameters superficially --
> some parameters of "plot" (like log) are related to the shape of the axes,
> and should be inherited from what is on the plot already.

I'd say causing some parameters to be completely ignored without a 
warning is more than a superficial interaction.  Really, add=TRUE is not 
a great design:  it would be better to say "plot methods draw a new 
plot" (so they need args for all the decorations like axes, titles, 
etc.), and have other ways to add things to plots.  Hadley was right on 
this, his ggplot2 has a better thought-out design than classic graphics. 
   However, we have what we have.

>> What you really seem to want is to add it to the generic plot(),
> 
> Agreed.
> 
>> but it's way too late to go modifying that particular generic.
> 
> I agree.  Adding an "add=FALSE" parameter to plot() would generate errors for
> methods that don't implement it, so they would all have to be changed
> simultaneously, including in private/unreleased code.
> 
> So I'd like to settle for second best: adding add=FALSE parameters to many plot
> methods.

I like that suggestion better than adding it here and there, one at a 
time.  So, to advance the discussion:  can you take a look at the plot 
methods that are in the base and recommended packages, and work out how 
many already have it, how many would be improved if it was added, and in 
how many cases it just wouldn't make sense?  (You could also do this on 
all the CRAN and Bioconductor packages, but that would be about 100 
times more work: about 50 times as many packages, and much less 
consistency in the programming and documentation standards.  Maybe on a 
subset of popular ones, e.g. those that Rcmdr suggests?)

Data like that could make a convincing argument that the effort of 
adding this to the base packages is worthwhile.  (To get it added to 
non-base packages will require you to convince their maintainers that 
it's a good idea.)  Another helpful part of the argument will be for you 
to volunteer to do the work of both code and documentation updates.

Duncan Murdoch