Martin,
I agree that global options settings that affect computations are
problematic.
But that's not the issue I was addressing. If for some classes, func.CLASS
has certain defaults for some arguments, it is surprising that for other
classes, it has different defaults, whether these defaults are fixed or
taken from global settings -- when there is no obvious reason for the
default to vary by class.
-s
On Fri, Jan 22, 2010 at 3: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.
>
> From this (my) point of view, we should strive to eventually deprecate
> default.stringsAsFactors() which basically returns
> getOption("stringsAsFactors"),
> or as first/2nd step redefine it as
>
> default.stringsAsFactors <- function() TRUE
>
> Martin Mächler.
>
> SM> Thanks,
> SM> -s
>
[[alternative HTML version deleted]]
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
