Simon, I agree, for some (maybe most) arguments it is good to know what
defaults are being used. But there are some for which I really don't want
to know. An example of the latter is arguments that control interaction
with a database. Suppose I have a low-level interaction function that
take
Tony, I don't understand what you mean. Could you give
an example?
> -Original Message-
> From: Tony Plate [mailto:[EMAIL PROTECTED]
> > ... I'm not saying "never write functions that use ...",
> >I'm just saying "never write functions that depend on a particular
> >argument being passed v
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 c
Thanks for the insight.
> -Original Message-
> From: Prof Brian Ripley [mailto:[EMAIL PROTECTED]
> dots <- list(...)
> haveYlim <- "ylim" %in% names(dots)
>
> is the sort of thing we still understand 5 years later.
>
I didn't say "understand", I said "easily follow". Obviously how
"easi
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 cl
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 month
