Re: [Rd] An update method for lists?

From: Gabor Grothendieck <ggrothendieck_at_gmail.com>
Date: Mon 18 Sep 2006 - 22:51:57 GMT

It would be nice if the .Rd file had one or more examples since its not that easy to otherwise understand what it does. Regards.

On 9/18/06, Deepayan Sarkar <deepayan.sarkar@gmail.com> wrote:
> On 9/15/06, Deepayan Sarkar <deepayan.sarkar@gmail.com> wrote:
> > On 9/15/06, Martin Maechler <maechler@stat.math.ethz.ch> wrote:
> > > >>>>> "DeepS" == Deepayan Sarkar <deepayan.sarkar@gmail.com>
> > > >>>>> on Fri, 15 Sep 2006 12:22:15 -0700 writes:
> > >
> > > DeepS> Hi, since lattice uses nested lists in various
> > > DeepS> situations, it has had an unexported function called
> > > DeepS> updateList for a while, which looks like
> > >
> > > >> > lattice:::updateList
> > > >> function (x, val)
> > > >> {
> > > >> if (is.null(x))
> > > >> x <- list()
> > > >> if (!is.list(x))
> > > >> stop("x must be NULL or a list")
> > > >> if (!is.list(val))
> > > >> stop("val must be a list")
> > > >> xnames <- names(x)
> > > >> for (v in names(val)) {
> > > >> existing <- v %in% xnames
> > > >> if (existing && is.list(x[[v]]) && is.list(val[[v]]))
> > > >> x[[v]] <- updateList(x[[v]], val[[v]])
> > > >> else x[[v]] <- val[[v]]
> > > >> }
> > > >> x
> > > >> }
> > >
> > > [I'm not sure I'd allow NULL for 'x'; typing list() instead of
> > > NULL is not much more, but when the function name even includes 'list'
> > > I'd really require a list for 'x']
> >
> > Makes sense.
> >
> > > You could hence collapse the first 6 lines to the single
> > >
> > > stopifnot(is.list(x), is.list(val))
> >
> > I'll check if lattice needs some fixes with this.

>

> Actually, I do need to allow NULL, because update.trellis does things like
>

> update.trellis <- function(object, ..., par.strip.text, ...)
> {
> ...
> object$par.strip.text <- updateList(object$par.strip.text, par.strip.text)
> ...
> }
>

> where object$par.strip.text may be initially NULL. But I'll do that
> inside a lattice wrapper.
>

> > > DeepS> Basically, it recursively replaces elements that have
> > > DeepS> been specified in val, leaving the other components
> > > DeepS> alone. I'm not aware of any other actual situation
> > > DeepS> where this is useful, but it certainly can be, so I
> > > DeepS> want to export this functionaliy. At least one other
> > > DeepS> person (Gabor) has also asked for that.
> > >
> > > I've had a similar need only recently:
> > > If a list is used to store "defaults" and you want a safe way to
> > > change only a few of the values...
> > > I presume you use this for manipulating the settings of lattice
> > > parts ?
> >
> > Yes, it's primarily used inside trellis.par.set, but many other places as well.
> >
> > > DeepS> Now, as the name suggests, I think it might be
> > > DeepS> reasonable to export this as an update method for
> > > DeepS> "list" objects. Depending on what others (in
> > > DeepS> particular r-core) think, one of these things might
> > > DeepS> happen:
> > >
> > > DeepS> (1) I export it as updateList (or some other name) in lattice
> > > DeepS> (2) I export it as an S3 method update.list in lattice
> > > DeepS> (3) It gets added as an S3 method update.list in one of the base packages
> > > or
> > > (4) it gets added as utility function updateList() to
> > > 'utils' {= one of the base packages}
> >
> > Yes, that a good option too (certainly better than (1))
> >
> > > which I'd favor momentarily.
> > > - update() is typically for updating *models*
> > > - it's not clear that this is *the* method for update()ing a list
> >
> > I agree. Part of the reason I brought this up is because it is not
> > clear to me what justifies a new method for an existing generic. An
> > argument for is that one doesn't introduce yet another function, which
> > (I thought) might be enough if the other choice is to not have any
> > method at all.
> >
> > > I'm also a bit wondering if it wouldn't make sense to change the name to
> > > something like assignInList().
> >
> > I'm open to suggestions for the name. I didn't think too much about it
> > since it was unexported anyway.
> >
> > > DeepS> The default option is (1), and I guess Sept 19 is the deadline for any
> > > DeepS> of these to be included in R 2.4.0.
> > >
> > > Yes, that's true for (3) & (4) are higher if you provide a patch
> > > to R-devel (not R-alpha) which includes a man page ... [but
> > > don't hurry, I'd like to see other comments]
>

> I have checked in
>

> https://svn.r-project.org/R-packages/trunk/lattice/R/modifyList.R
> https://svn.r-project.org/R-packages/trunk/lattice/man/modifyList.Rd
>

> which I'm happy to offer for inclusion in utils or wherever might seem
> appropriate. I'll upload a version of lattice which includes these
> late tomorrow if I don't see any more comments by then.
>

> I've changed the name because I wasn't sure if assignInList might be
> confusing, as the semantics are different from those of assign (assign
> is like 'fix', while this is more like 'edit'). However, any name is
> fine with me.
>

> Deepayan
>

> ______________________________________________
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel Received on Tue Sep 19 08:54:58 2006

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.1.8, at Mon 18 Sep 2006 - 23:30:07 GMT.

Mailing list information is available at https://stat.ethz.ch/mailman/listinfo/r-devel. Please read the posting guide before posting to the list.