[R] Age of an object?

[Martin Maechler]

>>>>> "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
}

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