[R] Age of an object?

[Duncan Temple Lang]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Roger Bivand wrote:
> On Wed, 14 Dec 2005, Martin Maechler wrote:
> 
> 
>>>>>>>"Kjetil" == Kjetil Brinchmann Halvorsen <kjetilbrinchmannhalvorsen at gmail.com>
>>>>>>>    on Wed, 14 Dec 2005 08:59:24 -0400 writes:
>>
>>    Kjetil> Philippe Grosjean wrote:
>>    >> Martin Maechler wrote:
>>    >>>>>>>> "Trevor" == Trevor Hastie <hastie at stanford.edu>
>>    >>>>>>>> on Tue, 13 Dec 2005 12:51:34 -0800 writes:
>>    >>> 
>>    Trevor> It would be nice to have a date stamp on an object.  
>>
>>    Kjetil> Following up on my post of a few minutes ago, I tried to write an
>>    Kjetil> timestamp function
>>
>>    Kjetil> timestamp <- function(obj, moretext){
>>    Kjetil> comment(obj) <<- paste(Sys.time(), moretext, sep="\n")
>>    Kjetil> }
>>
>>    Kjetil> but this does'nt work.
>>
>>    >> myobj <- 1:10
>>    >> timestamp(myobj, "test")
>>    Kjetil> Error in timestamp(myobj, "test") : object "obj" not found
>>    >> 
>>
>>Instead, I'd **strongly** recommend to define *two* functions,
>>one "constructor" and one "inspector" :
>>
>>"timestamp<-" <- function(obj, value) {
>>    stamp <- paste(Sys.time(), value)
>>    ## attr(obj,"timestamp") <- stamp
>>    comment(obj) <- stamp
>>    obj
>>}
> 
> 
> This does treat any existing comment rather brutally, could stamp rather 
> be:
> 
>     stamp <- paste(Sys.time(), comment(obj), value)
> 
> probably enhanced with some field separators to let the inspector grab 
> just its chunk? Something like DCF?


Why not use a regular named vector/list rather than pasting things into
and then back from a string, relying on conventions and losing
information.

   current <- comment(obj)
   current[["timeStamp"]] <- Sys.time()
   comment(x) <- current

and then the individual elements can be accessed in the usual manner
   comment(x)[["timeStamp"]]
and the original value can be be maintained (with a little more
tinkering for old-style cases without named elements).


> 
> 
>>## and
>>
>>timestamp  <- function(obj) {
>>    ## attr(obj,"timestamp")
>>    comment(obj)
>>}
>>
>>## and the usage (shown with output)
>>
>>myobj <- 1:9
>>timestamp(myobj) <- "as an example"
>>
>>myobj
>>## 1 2 3 4 5 6 7 8 9
>>timestamp(myobj)
>>## "2005-12-14 14:57:33 as an example"
>>
>>-------
>>
>>we had mentioned recently here that "good programming style"
>>works with functions that do *not* modify other objects but
>>rather *return*..
>>
>>
>>
>>    >>> 
>>    Trevor> In S/Splus this was always available, because objects were files.
>>    >>> 
>>    >>> [are you sure about "always available"? 
>>    >>> In any case, objects were not single files anymore for a
>>    >>> long time, at least for S+ on windows, and AFAIK also on
>>    >>> unixy versions recently ]
>>    >>> 
>>    >>> This topic has come up before.
>>    >>> IIRC, the answer was that for many of us it doesn't make sense
>>    >>> most of the time: 
>>    >> 
>>    >> I remember it was discussed several times. I don't remember why it was 
>>    >> considered too difficult to do.
>>    >> 
>>    >>> If you work with *.R files ('scripts') in order to ensure
>>    >>> reproducibility, you will rerun -- often source() -- these files,
>>    >>> and the age of the script file is really more interesting.
>>    >>> Also, I *always* use the equivalent of  q(save = "no") and
>>    >>> almost only use save() to particularly save the results of
>>    >>> expensive  computations {often, simulations}.
>>    >> 
>>    >> OK, now let me give examples where having such an information would ease 
>>    >> the work greatly: you have a (graphical) view of the content of an 
>>    >> object (for instance, the one using the "view" button in R commander), 
>>    >> or you have a graphical object explorer that has a cache to speed up 
>>    >> display of information about objects in a given workspace (for instance, 
>>    >> the SciViews-R object explorer). What a wonderful feature it will be to 
>>    >> tell if an object was changed since last query. In the view, one could 
>>    >> have a visual clue if it is up-to-date or not. In the object explorer, I 
>>    >> could update information only for objects that have changed...
>>    >> 
>>    Trevor> I have looked around, but I presume this information is not available.
>>    >>> 
>>    >>> I assume you will get other answers, more useful to you, which
>>    >>> will be based on a class of objects which carry an
>>    >>> 'creation-time' attribute.  
>>    >> 
>>    >> Yes, but that would work only for objects designed that way, and only if 
>>    >> the methods that manipulate that object do the required housework to 
>>    >> update the 'last-changed' attribute (the question was about last access 
>>    >> of an object, not about its creation date, so 'last-changed' is a better 
>>    >> attribute here). If you access the object directly with, let's say, 
>>    >> myobject at myslot <- newvalue, that attribute is not updated, isn't it?
>>    >> 
>>    >> Best,
>>    >> 
>>    >> Philippe Grosjean
>>    >> 
>>    >>> Martin Maechler, ETH Zurich
>>    >>>
>>
>>______________________________________________
>>R-help at stat.math.ethz.ch mailing list
>>https://stat.ethz.ch/mailman/listinfo/r-help
>>PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
>>
> 
> 

- --
Duncan Temple Lang                duncan at wald.ucdavis.edu
Department of Statistics          work:  (530) 752-4782
371 Kerr Hall                     fax:   (530) 752-7099
One Shields Ave.
University of California at Davis
Davis, CA 95616, USA
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (Darwin)

iD8DBQFDoC4n9p/Jzwa2QP4RAiJUAJ9nCsmUSEuUwnssgwfcl+qdJ/oDlACeK6jw
r6QsjGFUtuPhKCd31dZX5Iw=
=jCmV
-----END PGP SIGNATURE-----