>> Some of us (including me) have strongly argued on several
>> occasions that global options() settings should *not* have an
effect
>> on anything "computing" ...
> ...
Global options are less of a problem where a function allows them to be
overridden by the user or programmer. If something is affected by a
global option, a programmer desiring consistent behaviour then has a
simple recourse - set it explicitly in the call. In other words, the
programmer should be able to enforce that principle of functional
programming; an observation which I would offer as a wider imperative
than the language having to do so. That is, I believe that 'it should
always be possible for a user to set any parameter used by a function'
irrespective of the existence or otherwise of global options. (I believe
in programmer choice in these things).
In a sense, too, a global option expresses a user choice for a set of
operations. There are often good reasons for this; for example, factor
contrasts. It has drastic effects on the model computed, but there seems
good reason for the convenience of allowing a user to set contrasts for
a series of related analyses rather than setting them individually on
each model call.
The (small number of pretty much trivial) defaults that have, over the
last few years, given me a temporary headache are not globals or
argument defaults; they have been hardwired defaults that couldn't be
changed in the function calls. Rewriting the function is almost always
possible, but not quite a straightforward method of overriding a
default! To an extent, the same can be said of global options that
affect a function, are user-settable but can't be overridden in the call
itself. The main 'culprits' of this tend to be older graphics calls,
which often respect par() options but don't all take all the par()
options in '...' .
But in general I too concur; there shouldn't be global options without
pretty good reason.
>Which isn't to say I don't think that you're right - I would hate for
>R to head in the direction of PHP ....
PHP is indeed an example to stay away from; it changes the nature of
data without allowing a test on the stored data to reveal the fact. By
contrast, stringsAsFactors produces a _detectable_ effect on the data;
we can tell what form the data has now, irrespective of system settings
now or (worse) on original input.
Steve Ellison
*******************************************************************
This email and any attachments are confidential. Any use...{{dropped:8}}
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
