Just don't do it, surely? (was RE: [R] Retrieve ... argument values)

[Tony Plate]

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 
takes an argument 'db.mode', where this specifies a way of interacting with 
the database.  Now, if I also have a higher level function that gets data 
from the database I might write:

db.get.high.level.data <- function(what, ...) {
      processed.what <- do something to 'what'
      db.get.low.level.data(processed.what, ...)
}

db.get.low.level.data(what, db.mode=2) {
      # fetch the data
}

By using ... arguments I can specify a db.mode argument to the higher level 
function, or just get the default provided in the lower level function.  If 
I then change the lower level function to provide a better mode of 
interaction I can make that mode the default in the lower level function, 
and be confident it will be used everywhere.  But if I specify the defaults 
in both places, then changing defaults becomes a big task.

As for the second point regarding different functions having different 
defaults for an argument of the same name, it can certainly be handled as 
you describe by making different argument names in the higher level function.

-- Tony Plate

At Wednesday 05:25 PM 9/17/2003 +0100, Simon Fear wrote:
>Tony, I don't understand what you mean. Could you give
>an example?
>
> > -----Original Message-----
> > From: Tony Plate [mailto:tplate at blackmesacapital.com]
> > > ... 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.
>
>I don't think I agree with that (though maybe I just didn't
>get it). I prefer to know what arguments a function is going
>to use.
>
> > 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.
>
>I'm lost there. When I choose which function to call it has
>its own default??
>
>I often call a function of mine called timepoints.summary for which I
>want
>to pass graphical parameters to boxplots, matplots and confidence
>interval plots. So I name the arguments cex.boxplot, col.boxplot etc
>and then within the function I call boxplot(x, cex=boxplot.cex) and so
>on. I wouldn't expect a single argument "cex" to magically work out
>whether it was being used in a boxplot or matplot and change
>to a different default??
>
>
>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
>contains information which may be legally privileged.  It is
>intended for the stated addressee(s) only.  Access to this
>email by anyone else is unauthorised.  If you are not the
>intended addressee, any action taken (or not taken) in
>reliance on it, or any disclosure or copying of the contents of
>it is unauthorised and unlawful.  If you are not the addressee,
>please inform the sender immediately and delete the email
>from your system.
>
>This message and any associated attachments have been
>checked for viruses using an internationally recognised virus
>detection process.  However, Internet communications cannot
>be guaranteed to be secure or error-free as information could
>be intercepted, corrupted, lost, destroyed, arrive late or
>incomplete. Therefore, we do not accept responsibility for any
>errors or omissions that are present in this message, or any
>attachment, that have arisen as a result of e-mail transmission.
>If verification is required, please request a hard-copy version.
>Any views or opinions presented are solely those of the author
>and do not necessarily represent those of Syne qua non.