Re: [Rd] An update method for lists?

From: Deepayan Sarkar <>
Date: Fri 15 Sep 2006 - 20:54:07 GMT

On 9/15/06, Martin Maechler <> wrote:
> >>>>> "DeepS" == Deepayan Sarkar <>
> >>>>> 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.

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

-Deepayan mailing list Received on Sat Sep 16 06:56:35 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 Please read the posting guide before posting to the list.