[Rd] Minor Infelicity in Printing of Objects Nested in Lists
||one| @end|ng |rom r@tud|o@com
Sun May 10 18:22:13 CEST 2020
The main reason for resetting the tagbuf in `print.default()` and
other entry points to the print routine is that it is currently not
reset on exit. Creating a context to reset it on exit to its last
value might work. This should be done in the entry points rather than
in print-value-rec though, since callers of the latter might write to
Another solution to this problem is proposed with the first patch in
https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17610. Maybe I
should extract this patch into its own entry so the discussion can be
separate from the other patches.
The idea is to pass the tag buffer as argument to the `print()`
generic so it can be passed again to `print.default()`. The added
benefit is that print methods can then pass their own tagbuf, which
should be useful for printing special list-like objects.
The downside is that it is technically a breaking change for methods
that pass their dots to other functions (there's a couple of
occurrences of this in the base packages). However I think such usage
is not recommended for print methods because `print()` is a recursive
generic that dispatches on heterogeneous objects. For example the user
might pass `digits = 2` to print a list of objects. The print methods
should make sure they ignore any unknown arguments.
On 5/10/20, brodie gaslam via R-devel <r-devel using r-project.org> wrote:
> Currently S3 objects nested in generic vectors cause the tag buffer to be
> reset. This feels sub-optimal for those objects that don't have a print
> $a$b ### <<<< notice "$a$b"
>  "hello"
>> list(a=structure(list(b='hello'), class='world'))
> $b ### <<<< notice "$b", not "$a$b"
>  "hello"
>  "world"
> This happens because the default print method resets the tag buffer anytime
> it's called, whether by a custom print method, or by internal C code as
> part of the recursion into objects in `printValueRec`.
> One possible way to "fix" this is to make it the responsibility of
> `printValueRec` to reset the tag buffer on exit from the top level, but that
> would mean always having an active context to catch errors instead of just
> for win32 as is the case now. Additionally, print method authors may
> themselves intentionally rely on `print.default` for some parts their
> output, in which case it may be desirable to reset the tag buffer.
> Obviously not a big deal. In my use case it can make it difficult to
> identify what part of a complex object caused a difference in a diff with a
> few neighboring context lines. Just mentioning it in case there is interest
> in doing something about it. If so I'll be happy to create a bugzilla
> ticket and assist with patches/testing.
> R-devel using r-project.org mailing list
More information about the R-devel