Age of an object?

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?

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