> > attributes(my_obj)[[my_attr_name]] <- my_attr_value > > ...fails when my_obj doesn't already have an attribute named my_attr_name.
Do you have an example of this? In R-2.15.3 I don't see that problem: > my_obj <- 37:41 > my_attr_name <- "myAttr" > my_attr_value <- as.roman(2012:2013) > attributes(my_obj)[[my_attr_name]] <- my_attr_value > my_obj [1] 37 38 39 40 41 attr(,"myAttr") [1] MMXII MMXIII > attributes(my_obj)[["anotherAttrName"]] <- "another attribute value" > my_obj [1] 37 38 39 40 41 attr(,"myAttr") [1] MMXII MMXIII attr(,"anotherAttrName") [1] "another attribute value" Bill Dunlap Spotfire, TIBCO Software wdunlap tibco.com > -----Original Message----- > From: r-help-boun...@r-project.org [mailto:r-help-boun...@r-project.org] On > Behalf > Of Murat Tasan > Sent: Friday, May 10, 2013 8:16 AM > To: Duncan Murdoch > Cc: r-help@r-project.org > Subject: Re: [R] attr vs attributes > > thanks, both. > > the only real difference between the two approaches that i can see is when > assigning _new_ attributes to an object where the attribute name is itself > variable. > something like this: > > > attributes(my_obj)[[my_attr_name]] <- my_attr_value > > ...fails when my_obj doesn't already have an attribute named my_attr_name. > BUT(!) it does work just fine when the attribute named my_attr_name is > already attached to my_obj. > > i guess in the end attr(...) is just easier, but i can also see a spot of > confusion in the 'attributes(x)[[y]] <- z' working sometimes for folks and > sometimes not. > > (to be clear, it's pretty easy to figure out when it does and doesn't work, > but if there's a new programmer coming along and it works the first time, > when the upstream code changes a bit (i.e. the attribute name changes) and > this attribute-setting line then fails, it could be very confusing :-) > > thanks for the thoughts! > > cheers, > > -m > > > > > On Fri, May 10, 2013 at 10:58 AM, Duncan Murdoch > <murdoch.dun...@gmail.com>wrote: > > > On 10/05/2013 10:50 AM, Rui Barradas wrote: > > > >> Hello, > >> > >> There's at least one example where only the form attr(x, "foo") <- "bar" > >> would work, not the other form. If you want to set attributes > >> programatically, use the first form, like in the function below. Note > >> that the example is artificial. > >> > >> > >> setAttr <- function(x, attrib, value){ > >> attr(x, attrib) <- value > >> x > >> } > >> > >> x <- 1:4 > >> setAttr(x, "foo", "bar") > >> > >> > >> You cannot make > >> > >> attribute(x)$attrib <- value > >> > > > > But > > > > attributes(x)[[attrib]] <- value > > > > would be fine. I don't know why Murat thought there would be different > > consistency checks; I'd assume the main difference would be that attr() > > would be quicker. (It does a lot less: attributes(x)[[attrib]] <- value > > essentially does > > > > temp <- attributes(x) > > temp[[attrib]] <- value > > attributes(x) <- temp > > > > and there are a lot of wasted operations there.) > > > > Duncan Murdoch > > > > > > > >> > >> Hope this helps, > >> > >> Rui Barradas > >> > >> Em 09-05-2013 18:35, Murat Tasan escreveu: > >> > hi all -- i looked through the R Language Definition document, but > >> couldn't > >> > find any particular warning or example that would clarify the best use > >> of > >> > attribute setting for R objects. > >> > > >> > let x be some R object, and i'd like to add attribute "foo" with value > >> > "bar". > >> > > >> > case 1: > >> >> attr(x, "foo") <- "bar" > >> > > >> > case 2: > >> >> attributes(x)$foo <- "bar" > >> > > >> > in both cases, attributes(x) reveals the appropriate setting has taken > >> > place. > >> > i'm assuming that attr(...) is 'safer' in the sense that perhaps > >> > consistency checks are made? > >> > (almost like a generic accessor/setter method?) > >> > but i also haven't seen any examples where case 2 (above) would bad... > >> is > >> > there are trivial such example out there? > >> > > >> > BTW -- the cause for interest here is when dealing with dendrogram > >> objects, > >> > for which much of the useful data are stored as attributes, and where > >> > running dendrapply means having to explicitly set attribute values to > >> > retain the tree structure in the resulting object. > >> > > >> > cheers, > >> > > >> > -m > >> > > >> > [[alternative HTML version deleted]] > >> > > >> > ______________________________**________________ > >> > R-help@r-project.org mailing list > >> > https://stat.ethz.ch/mailman/**listinfo/r- > help<https://stat.ethz.ch/mailman/listinfo/r-help> > >> > PLEASE do read the posting guide http://www.R-project.org/** > >> posting-guide.html <http://www.R-project.org/posting-guide.html> > >> > and provide commented, minimal, self-contained, reproducible code. > >> > > >> > >> ______________________________**________________ > >> R-help@r-project.org mailing list > >> https://stat.ethz.ch/mailman/**listinfo/r- > help<https://stat.ethz.ch/mailman/listinfo/r-help> > >> PLEASE do read the posting guide http://www.R-project.org/** > >> posting-guide.html <http://www.R-project.org/posting-guide.html> > >> and provide commented, minimal, self-contained, reproducible code. > >> > > > > > > [[alternative HTML version deleted]] > > ______________________________________________ > R-help@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-help > PLEASE do read the posting guide http://www.R-project.org/posting-guide.html > and provide commented, minimal, self-contained, reproducible code. ______________________________________________ R-help@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.