From h.wickham at gmail.com  Fri Jan 22 14:47:09 2010
From: h.wickham at gmail.com (hadley wickham)
Date: Fri, 22 Jan 2010 07:47:09 -0600
Subject: [Rd] Inconsistency in as.data.frame.table for stringsAsFactors
In-Reply-To: <f8e6ff051001220545h7318068s849bf22e074cb363@mail.gmail.com>
References: <8b356f881001211719o20f814a2w488aec8d648fc5f5@mail.gmail.com> 
	<19289.24362.734838.778263@lynne.math.ethz.ch>
	<f8e6ff051001220545h7318068s849bf22e074cb363@mail.gmail.com>
Message-ID: <f8e6ff051001220547o2921e92chc014f68bd8a6c3ea@mail.gmail.com>

>> Some of us (including me) have strongly argued on several
>> occasions that ?global options() settings should *not* have an effect
>> on anything "computing" but just on "output"
>> i.e. printing/graphing of R results.
>> As it is currently, potentially R scripts and R functions may
>> only work correctly for one setting of
>> ? ? options( stringsAsFactors = * )
>> which is against all principles of functional programming.
>
> A similar argument would also seem to apply to defaultPackages,
> deparse.max.lines, download.file.method, encoding, expressions, warn
> and na.action. ?There are plenty of functions in R that violate other
> principles of functional programming, so, by itself, this argument
> seems a little weak to me. ?There are obviously differences of opinion
> about this issue in R core, and it's unfortunate that the user has to
> be exposed to them through inconsistent function definitions.

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 where every script has to check
three or four different global variables in order to work on all
installations.

Hadley

-- 
http://had.co.nz/



[Rd] Inconsistency in as.data.frame.table for stringsAsFactors
hadley wickham