Re: [Rd] Inconsistency in as.data.frame.table for stringsAsFactors

From: S Ellison <S.Ellison_at_lgc.co.uk>
Date: Fri, 22 Jan 2010 14:25:50 +0000

>> 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_at_r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel Received on Fri 22 Jan 2010 - 14:30:44 GMT

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.2.0, at Fri 22 Jan 2010 - 18:00:18 GMT.

Mailing list information is available at https://stat.ethz.ch/mailman/listinfo/r-devel. Please read the posting guide before posting to the list.

list of date sections of archive