>>>>> Henrik Bengtsson
>>>>> on Tue, 7 Jan 2020 13:31:18 -0800 writes:
> On Tue, Jan 7, 2020 at 6:14 AM brodie gaslam via R-devel
> <r-devel@r-project.org> wrote:
>>
>> For whatever my 2c are worth I think this would be nice. I'm still
uncomfortable at having to call `options` in my package `diffobj` to set output
width.
> Adding a few more cents: It might be worth considering "who" should be
> allow to control the 'width' argument.
Well, I tend to disagree; this is not about control (and playing
police .. ;-).
Everbody can set options() even now and that is a pretty bad
thing unless they are properly localized
{with which I mean: It's +- okay, if you use
- in a function
op <- options(..) ; on.exit(options(op))
- in a script
op <- options(..)
................
................
options(op)
}
and yes I know people even invented withOptions(...) etc.
Good programmring style for *functions* according to my book is
to have them depend only on their arguments, and if a global
option really (reall? think twice!) should influence behavior,
there should be arguments of the function which have a default
determined by the global option.
{ And then in my personal style book, global options should never
influence anything but "output" {print, plot, ..} and so the
stringsAsFactors global option is an atrocity and horror ......}
> In an interactive session,
> it's neat for the user to quickly be able to adjust 'width'. But in
> what cases should this be controlled by a (package) developer?
packages can set global options now which is much worse than
using it explicitly in some function calls.
Making 'width' an explicit argument {only in some cases, you
cannot do it for auto-printing of course!}
> What assumptions can the developer safely make about the 'width' of the
end
> user? I don't know the answer to this and I'm sure one can find valid
> cases where it makes sense to set the 'width' in a package - maybe
> like width = 0.90 * getOption("width", 80)?
Indeed.
I also would want to set width in tests/*.R where I use *.Rout.save
or even more often in \examples{..} in help pages
when printing things that look best, say with width=111
rather than the default 80.
> Could it be that print() ignoring 'width' has protected us from
> packages producing output with a fixed, hardcoded width that is set by
> the developer? If print() us updated to acknowledge 'width', will we
> start seeing print(..., width = 120) and so on in package code? Is
> this good or bad? This might be a complementary problem to what we
> have with 'stringsAsFactors' where the user's settings can override
> the intention of the developer.
> /Henrik
A good package developer will think many times before doing that
(but maybe do it in examples, as I mentioned); careless package
developers do all kind of things anyway.
R (and free software in general) is also about giving freedom to
useRs .. .. and some of us old folks know that with freedom
comes responsibility ..
Thank you, Henrik, for your valuable thoughts!
[Brodie G.:]
>> And since the topic is here, what about `show`? Feels like it should
accept `...` so that it too could be given some set of standard or non standard
parameters, including `width`.
I'm not proposing to touch show().
Very often when working with S4 objects, I devise a
sophisticated print() method, with defaults, (often times "smart",
i.e. depending on other arguments) for all but the first
argument and then the show() method just calls that print method.
Best, Martin
>> Happy new decade.
>> B.
>>
>> On Tuesday, January 7, 2020, 6:58:32 AM EST, Martin Maechler
<maech...@stat.math.ethz.ch> wrote:
>>
>> One of the things I often wish R would work with:
>>
>> When calling print() explicitly --- as I do not so rarely, e.g.,
>> specifying digits = <nd> ---
>> it sometimes seems awkward that from the printing options() ,
>> one can specify 'digits' and it has default digits = NULL which is
>> documented to be equivalent to digits = getOption("digits"),
>> but one cannot specify 'width'
>> ... well "even worse": one *can* specify 'width = .' but it is
>> silently ignored - as well documented on ?print.default
>>
>> Before considering to add this for R 4.0.0, doing the work
>> myself, I'd quickly wanted to hear opinions / caveats / .. about this.
>>
>> wishing you all a Happy New Year,
>> Martin
>>
>> Martin Maechler
>> ETH Zurich and R Core Team
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
