Re: [R] Age of an object?

From: Martin Maechler <>
Date: Thu 15 Dec 2005 - 01:00:43 EST

>>>>> "Kjetil" == Kjetil Brinchmann Halvorsen <> >>>>> on Wed, 14 Dec 2005 08:59:24 -0400 writes:

    Kjetil> Philippe Grosjean wrote:
>> Martin Maechler wrote:

    >>>>>>>> "Trevor" == Trevor Hastie <>
    >>>>>>>> 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

## and

timestamp <- function(obj) {

    ## attr(obj,"timestamp")

## and the usage (shown with output)

myobj <- 1:9
timestamp(myobj) <- "as an example"

## 1 2 3 4 5 6 7 8 9
## "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@myslot <- newvalue, that attribute is not updated, isn't it?
>> Best,
>> Philippe Grosjean
    >>> Martin Maechler, ETH Zurich
    >>> mailing list PLEASE do read the posting guide! Received on Thu Dec 15 01:09:08 2005

This archive was generated by hypermail 2.1.8 : Fri 03 Mar 2006 - 03:41:39 EST