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

[Gabor Grothendieck]

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/
> 
>