[Rd] Re: [R] Problem going back to a viewport with gridBase

[Gabor Grothendieck]

Just one additional item.  Look at:

?new.env

for an example of where this approach is used in R, noting the
hash= argument.

On 6/7/05, Gabor Grothendieck <ggrothendieck at gmail.com> wrote:
> Yes, I understand that although such order is convenient for
> the user as the significant reduction in code size here shows.  I
> wonder if there might be some performance parameter (e.g. hash)
> to control it.  If hash = TRUE then no guarantee is provided.  Otherwise
> order is kept.
> 
> On 6/7/05, Paul Murrell <p.murrell at auckland.ac.nz> wrote:
> > Hi
> >
> >
> > Gabor Grothendieck wrote:
> > > On 6/7/05, Paul Murrell <p.murrell at auckland.ac.nz> wrote:
> > >
> > >>Hi
> > >>
> > >>
> > >>Gabor Grothendieck wrote:
> > >>
> > >>>On 6/6/05, Paul Murrell <p.murrell at auckland.ac.nz> wrote:
> > >>>
> > >>>
> > >>>>Hi
> > >>>>
> > >>>>
> > >>>>Gabor Grothendieck wrote:
> > >>>>
> > >>>>
> > >>>>>On 6/2/05, Paul Murrell <p.murrell at auckland.ac.nz> wrote:
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>>Hi
> > >>>>>
> > >>>>>
> > >>>>>Thanks.  I have mucked around in vpTree structures and discovered its
> > >>>>>actually quite easy to specify children so I have changed my example
> > >>>>>so that instead of naming the children of 'layout' and then remembering
> > >>>>>coordinates linked to the names of the children of 'layout' in
> > >>>>>the 'coords' structure (which really just duplicates state information
> > >>>>>already available in grid) it simply follows the order
> > >>>>>of the children of 'layout' directly.  This permits elimination of 'coords'
> > >>>>>and the two naming functions.  Using the depth approach you advocate,
> > >>>>>'with' also becomes shorter and I think I have it to the point where it works
> > >>>>>with both vpPath and viewport classes.  Once Deepayan implements
> > >>>>>the use.viewport= argument to print, 'with' can be eliminated too.  No
> > >>>>>questions this time but I thought I would post the latest version for
> > >>>>>completeness. Regards.
> > >>>>
> > >>>>
> > >>>>Ok.  I can see this working ... for now.  The disadvantage with this
> > >>>>approach is that it makes use of the undocumented, internal structure of
> > >>>>a viewport tree to grab a list of child viewports.  A worse example of
> > >>>>the same thing is that the with() methods make use of a happy
> > >>>>coincidence that both viewport objects and viewport path objects share a
> > >>>>component called "name" (and an even happier coincidence that they
> > >>>>contain the same information).  I think it would be cleaner and better
> > >>>>practice, despite requiring longer code, to make use of the documented
> > >>>>interface which requires specifying viewport names and viewport paths.
> > >>>>The internal structure of objects is not guaranteed to be stable.
> > >>>
> > >>>
> > >>>Perhaps accessor functions could be provided that allow one to
> > >>>retrieve the name of a viewport and the name of a vpPath in
> > >>>a safe way.  These could be as simple as:
> > >>>
> > >>>names.viewport <- names.vpPath <- function(x) x$name
> > >>
> > >>
> > >>Fair enough.  If I say "use the API", I should provide a useful API :)
> > >>
> > >>This is a reasonable request for viewports;  the "name" component of a
> > >>viewport is a sensible thing to want.
> > >>
> > >>OTOH, it is not necessarily reasonable for a viewport path;  not all
> > >>components of an object should necessarily have accessors.  The "name"
> > >>component of a viewport path is the last element in the path.  Perhaps
> > >>an API should be supplied for extracting parts of a viewport path, but
> > >>it should probably be something along the lines of car()/cdr() or
> > >>head()/tail() or explode() to get different bits of the path.
> > >>
> > >>Accessing the children of a viewport is subtly problematic too.
> > >>Directly accessing the "children" slot and using the order of the
> > >>children in that slot is "dangerous" because there is no claim made by
> > >>the system as to how the children are internally ordered.  Again, it
> > >>works currently, but it makes incorrect assumptions about what the
> > >>system is doing internally so is vulnerable to future changes.
> > >
> > >
> > > That is the point of an accessor.  If the internals change then the
> > > accessor is modified to hide the change so that the user using the
> > > accessor is not impacted.
> > >
> > > It seems that grid already partly supports this with the childNames
> > > function.  It could be made generic and a method provided
> > > to cover the classes discussed here too.
> >
> >
> > I agree that a childNames() method for a viewport tree is probably
> > reasonable.  The subtle problem is the fact that your code makes use of
> > the *order* of the names that function would return, when in fact there
> > is no claim that they will be in any particular order.
> >
> > Paul
> >
> >
> > >>So again, the recommended approach is to use the API provided;  you
> > >>provide the naming scheme for viewports and you control the order in
> > >>which viewports are used.
> > >>
> > >>Paul
> > >>
> > >>
> > >>
> > >>>Similarly an accessor function to safely retrieve the children would
> > >>>be nice.    Again, it should ideally be possible to
> > >>>have a generic with methods for various grid classes.
> > >>>
> > >>>Then the  relevant line in the code concerning name
> > >>>could be written in a safe way like this:
> > >>>
> > >>>depth <- if (data$name == "ROOT") 0 else downViewport(names(data))
> > >>>
> > >>>and similarly for the children.
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>>Paul
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>>[pushLayout is same as before except there are no names on the
> > >>>>>children of 'layout' and the rest is new]
> > >>>>>
> > >>>>>library(grid)
> > >>>>>library(lattice)
> > >>>>>
> > >>>>>pushLayout <- function(nr, nc, name="layout") {
> > >>>>> pushViewport(viewport(layout=grid.layout(nr, nc), name=name))
> > >>>>> for (i in 1:nr) {
> > >>>>>   for (j in 1:nc) {
> > >>>>>     pushViewport(viewport(layout.pos.row=i, layout.pos.col=j))
> > >>>>>     upViewport()
> > >>>>>   }
> > >>>>> }
> > >>>>> upViewport()
> > >>>>>}
> > >>>>>
> > >>>>>with.vpPath <- with.viewport <- function(data, expr, ...) {
> > >>>>>     # if data is a vpPath it cannot be ROOT since NULL will never
> > >>>>>dispatch here
> > >>>>>     depth <- if (data$name == "ROOT") 0 else downViewport(data$name)
> > >>>>>     result <- eval.parent(substitute(expr))
> > >>>>>     upViewport(depth)
> > >>>>>     invisible(result)
> > >>>>>}
> > >>>>>
> > >>>>>grid.newpage()
> > >>>>>
> > >>>>># specify number of cells to fill and number of rows
> > >>>>>n <- 5; nr <- 3
> > >>>>>
> > >>>>>nc <- ceiling(n/nr)
> > >>>>>downViewport(pushLayout(nr, nc))
> > >>>>>
> > >>>>>vpt <- current.vpTree(all = FALSE)
> > >>>>>for(k in 1:n) with(vpt$children[[k]],
> > >>>>>     print( xyplot(v ~ v, list(v = 1:k)), newpage = FALSE )
> > >>>>>)
> > >>>>
> > >>>>
> > >>>>--
> > >>>>Dr Paul Murrell
> > >>>>Department of Statistics
> > >>>>The University of Auckland
> > >>>>Private Bag 92019
> > >>>>Auckland
> > >>>>New Zealand
> > >>>>64 9 3737599 x85392
> > >>>>paul at stat.auckland.ac.nz
> > >>>>http://www.stat.auckland.ac.nz/~paul/
> > >>>>
> > >>>
> > >>
> > >>--
> > >>Dr Paul Murrell
> > >>Department of Statistics
> > >>The University of Auckland
> > >>Private Bag 92019
> > >>Auckland
> > >>New Zealand
> > >>64 9 3737599 x85392
> > >>paul at stat.auckland.ac.nz
> > >>http://www.stat.auckland.ac.nz/~paul/
> > >>
> > >
> > >>
> >
> >
> > --
> > Dr Paul Murrell
> > Department of Statistics
> > The University of Auckland
> > Private Bag 92019
> > Auckland
> > New Zealand
> > 64 9 3737599 x85392
> > paul at stat.auckland.ac.nz
> > http://www.stat.auckland.ac.nz/~paul/
> >
> >
>