[R] Age of an object?

[Peter Dalgaard]

[Got stuck in the mail filter: "Too many recipients". Cancelled and
resending.] 

Duncan Temple Lang <duncan at wald.ucdavis.edu> writes:

> In addition to what and how to associate time information
> with an object, I imagine Trevor was also expecting that
> it would be done automatically rather than require
> the user to set the timestamp explicitly.
> To that end, the addTaskCallback()  function allows
> one to register a function that will be invoked at the
> end of each top-level task.  In that function
> call, one can update the timestamp on any (obviously) newly
> assigned value.  That will give the same behaviour as in S-Plus
> as there only top-level assignments are written to disk and so have
> a file modification time.

It's certainly not doable without some notion of "committing". If
every change to every object needs to be preceded by a lookup of the
current date+time, performance would vanish.

A similar, yet different, idea could be to have certain environments
flagged as "timestamped" and have assignment into that environment
check the flag and set the stamp. The obvious candidate for a
timestamped environment is .GlobalEnv, but there could be others.
The semantics of things like for() loops would require careful
attention, though.
 
>   D.
> 
> Henrik Bengtsson wrote:
> > If R would have timestamps telling when any object was last modified, we 
> > could extend R with a 'GNU make'-style functionality (or syntax) 
> > together with some fancy caching to persistent storage (files, data 
> > bases, ...).  That would really nice!  As B.R. and M.M. writes, 
> > timestamping is most suited for higher level data structures and not 
> > simple data types, because the over head would be too large.
> > 
> > /Henrik
> > 
> > 
> > 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.
> >>>
> >>>   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
> >>>
> >>>
> >>
> >>
> >>______________________________________________
> >>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
> >>
> >>
> > 
> > 
> > ______________________________________________
> > 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
> 
> ______________________________________________
> 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
> 

-- 
   O__  ---- Peter Dalgaard             Øster Farimagsgade 5, Entr.B
  c/ /'_ --- Dept. of Biostatistics     PO Box 2099, 1014 Cph. K
 (*) \(*) -- University of Copenhagen   Denmark          Ph:  (+45) 35327918
~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk)                  FAX: (+45) 35327907