[Bioc-devel] eset.Rnw revised in Biobase, please review

[Kevin Coombes]

Hi,

I think the history idea is extremely important (and useful). We analyze a 
lot of different microarray experiments. As a consequence, we often find 
ourselves in the position of having to go back and figure out exactly how a 
particular data set was analyzed when we are writing the methods section 
for the resulting article or grant proposal. Our experience is that the 
scripts that supposedly performed the analysis don't always match the 
objects that were saved, and so we have started implementing a 
comprehensive history mechanism that does update the history slot every 
time the object is created or modified. You can take a look at the 
implementation at
	http://bioinformatics.mdanderson.org/Software/OOMPA
To get this to work, however, we've had to turn processing functions into 
objects that know how to update the history slot. The benefit is that you 
can just ask the object what it's history is (or even put it into the 
summary method).

We're in the process of converting the various pieces of "expresso" into 
"Processor" and "Pipeline" objects so we can handle affymetrix arrays 
seamlessly, but the code isn't yet in a form that is suitable for public 
consumption.

Best,
	Kevin

--On Tuesday, September 06, 2005 7:19 AM -0700 Robert Gentleman 
<rgentlem at fhcrc.org> wrote:

> Hi Kasper,
>
> Kasper Daniel Hansen wrote:
>> Hi Vince and others
>>
>> Below is my first thoughts about the eSet class. I must say that I
>> like small "tight" classes with a strong validity checking.
>>
>> I will start with some specific comments:
>>
>> 1) The history slot: a reasonable idea. But if we have a specific
>> history slot, shouldn't it be filled automatically every time an eSet
>> is created or modified. That is, every replacement function or
>> initialization should update this slot. Otherwise I do not really see
>> the need to keep this slot separate from the notes.
>
>   I doubt that such a comprehensive approach will be useful, especially
> since we do not yet have a markup, or intended mechanism for display or
> managing the history mechanism. I suspect that at least initially less
> is going to be more helpful. Perhaps tracking changes to the
> expressions, or a few other slots would be a good first cut.
>
>>