Hi
The general "evolution" of grid.*() functions (that I have written) have
tended towards the grid.polyline() style ...
grid.*(...) {
grid.draw(*Grob(...))
}
With my thinking at least heading towards: if you are calling grid.*(),
then you want to actually draw something; if you want to just create a
description of something to draw, then you want to call *Grob().
In other words, I have come to view the 'draw' argument to grid.*() as
redundant.
That reflects how I use 'grid', so I may be unaware of an important
counter argument.
Paul
On 25/03/23 13:02, mikefc wrote:
Caution - Forged External Domain!
This e-mail cannot be validated and may not have been sent by the sender
shown in the 'From' field.
If you were not expecting to receive this e-mail we recommend you
contact the sender to confirm that they sent it.
If you believe this email was legitimately sent, we suggest the sender
notify their e-mail administrator that it has been received as a forged
(fake) e-mail by the University of Auckland.
Please contact the Staff Service Centre on extension 86000 if you
require further assistance.
Hi Paul and R-devel team,
There is an inconsistency in the definition of “grid.polyline” in
comparison to the other grid.* functions.
grid.polyline() simply passes all args (specified via … only) to
polylineGrob() and unconditionally calls grid.draw() on the returned object.
In contrast, all other functions in the grid.* family have a full set of
named arguments (reflecting the arguments to the *Grob() form of the
function). Internally to each of the grid.* family of functions, a draw
argument is used to enable/disable the drawing of the object at call time.
Is this a conscious choice? Should grid.polyline() behave like the
other grid.*() functions?
Kind regards,
Mike.
--
Dr Paul Murrell
Te Kura Tatauranga | Department of Statistics
Waipapa Taumata Rau | The University of Auckland
Private Bag 92019, Auckland 1142, New Zealand
64 9 3737599 x85392
p...@stat.auckland.ac.nz
www.stat.auckland.ac.nz/~paul/
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
