[R] Age of an object?

[Prof Brian Ripley]

On Sat, 14 Jan 2006, 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.

Because R does not store objects.  Rather R has a workspace, containing 
a collection of Ncells and Vcells which are pointed to by a look-up table 
of names (what people think of as objects) and with extensive 
cross-linking.

Suppose 'A' is a data frame.  What date is 'A'?  'A' consists of a list 
with elements the columns, and attributes including row.names.  All those 
columns and attributes can be shared with other objects, and it is 
possible to update them without copying the list.  So if you wanted the 
modification date of any part of the object you would need to tag every 
bit of it and do a search.  Adding a date to each bit would be a 
considerable overhead (remember R stores each string as a separate 
sub-object), and people are whining about the storage requirements 
already.

It would be possible to have a creation date on objects, but that is not 
what Philippe wants below.  Even that would need considerable surgery to 
deal with back-compatibility (saved objects would not have such a date).

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

Well, only if you believe objects have a separate existence, and perhaps 
the issue is one of mindset, as Martin Maechler has hinted.

I have to wonder why people who want S do not use it.

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

-- 
Brian D. Ripley,                  ripley at stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595