On Fri, Jan 22, 2010 at 2:17 AM, Martin Maechler <maech...@stat.math.ethz.ch> wrote: >>>>>> "SM" == Stavros Macrakis <macra...@alum.mit.edu> >>>>>> on Thu, 21 Jan 2010 20:19:28 -0500 writes: > > SM> I noticed that in as.data.frame.table, the stringsAsFactors argument > SM> defaults to TRUE, whereas in the other as.data.frame methods, it > defaults to > SM> default.stringsAsFactors(). > > SM> The documentation and implementation agree on this, so this is not a > bug. > > SM> However, I was wondering if this disparity was intended or if it might > be > SM> some sort of unintentional oversight. If it is intentional, I wonder > what > SM> the rationale is. > > 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. Hadley -- http://had.co.nz/ ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
