R help - Sep 2003 - Just don't do it, surely? (was RE: Retrieve ... argument values)

There have been various elegant solutions to test for the presence
of a particular named parameter within a ... argument, such as

if (!is.null(list(...)$ylim))
if ("ylim" %in% names(list(...)))

I think I'd have to comment these lines pretty clearly if I wanted
to easily follow the code in 6 months time. 

But I'm still not convinced it is ever a good idea to use this 
technique in preference to using explicit named arguments. If
there is something special about "ylim", why insist that it be 
passed within  "..." in the first place? Surely it's better
to define the function as function(x,ylim=default,...) within which
you do your special ylim stuff, then call plot(x, ylim=ylim,...))??

Can anyone come up with a good reason not to follow
that principle? I think my earlier post may have been
misconstrued: I'm not saying "never write functions that use ...",
I'm just saying "never write functions that depend on a particular 
argument being passed via ...".
 

Simon Fear
Senior Statistician
Syne qua non Ltd
Tel: +44 (0) 1379 644449
Fax: +44 (0) 1379 644445
email: Simon.Fear at synequanon.com
web: http://www.synequanon.com
 
Number of attachments included with this message: 0
 
This message (and any associated files) is confidential and\...{{dropped}}

On Wed, 17 Sep 2003, Simon Fear wrote:
> There have been various elegant solutions to test for the presence
> of a particular named parameter within a ... argument, such as
> 
> if (!is.null(list(...)$ylim))
> if ("ylim" %in% names(list(...)))
> 
> I think I'd have to comment these lines pretty clearly if I wanted
> to easily follow the code in 6 months time. 
Well, take a look at the R sources, as

dots <- list(...)
haveYlim <- "ylim" %in% names(dots)

is the sort of thing we still understand 5 years later.
> But I'm still not convinced it is ever a good idea to use this 
> technique in preference to using explicit named arguments. If
> there is something special about "ylim", why insist that it be 
> passed within  "..." in the first place? Surely it's better
> to define the function as function(x,ylim=default,...) within which
> you do your special ylim stuff, then call plot(x, ylim=ylim,...))??
> 
> Can anyone come up with a good reason not to follow
> that principle? 
Inadvertent partial matching for one.  If you must do this, put ylim after 
... or anything you try to pass through ... starting y, yl or yli will
be matched to ylim, as in
> foo <- function(x, ylim=NULL, ...) match.call()
> foo(y=1)
foo(ylim = 1)
> foo <- function(x, ..., ylim=NULL) match.call()
> foo(y=1)
foo(y = 1)

Were you aware of that?  (It's not clear to me that a lot of authors of R 
code have considered it carefully. It is in `S Programming'.)
> I think my earlier post may have been
> misconstrued: I'm not saying "never write functions that use
...",
> I'm just saying "never write functions that depend on a particular
> argument being passed via ...".
It is also conceptually simpler for groups of arguments, such as graphical 
parameters, to be treated consistently, possibly between groups of 
functions.  See plot.POSIXct for one of the possible elegant workarounds.

-- 
Brian D. Ripley,                  ripley at stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595

At Wednesday 11:19 AM 9/17/2003 +0100, Simon Fear wrote:
>There have been various elegant solutions to test for the presence
>of a particular named parameter within a ... argument, such as
>
>if (!is.null(list(...)$ylim))
>if ("ylim" %in% names(list(...)))
>
>I think I'd have to comment these lines pretty clearly if I wanted
>to easily follow the code in 6 months time.
>
>But I'm still not convinced it is ever a good idea to use this
>technique in preference to using explicit named arguments. If
>there is something special about "ylim", why insist that it be
>passed within  "..." in the first place? Surely it's better
>to define the function as function(x,ylim=default,...) within which
>you do your special ylim stuff, then call plot(x, ylim=ylim,...))??
>
>Can anyone come up with a good reason not to follow
>that principle? I think my earlier post may have been
>misconstrued: I'm not saying "never write functions that use
...",
>I'm just saying "never write functions that depend on a particular
>argument being passed via ...".
Several reasons for not following that principle involve proliferation of 
defaults -- if the lower level functions have defaults, then those defaults 
must be repeated at the higher levels.  This is a good reason for not 
following that principle, because it makes software maintenance more 
difficult.  Another reason for not following that principle is that tf you 
have several lower level functions with different default values for an 
argument of the same name, it becomes impossible to get the lower-level 
default behavior.

-- Tony Plate