[Bioc-devel] Stability of biobase eSets

[Sean Davis]

Martin Morgan wrote:
> Excellent and timely question!
> 
> 1. Our plan is to never again make changes at the very end of the
> development cycle. We also plan to move all our hosted experiment data
> to ExpressionSet over the next few weeks -- i.e., we think this is the
> future, and want to encourage feedback.

I personally like what I have been seeing.  I particularly like the 
environment storage (with the obvious potential for other types of 
storage down the road, from looking at the code...).

> 2. We have one change planned for the underlying data structure,
> hopefully to make a preview by the end of this week.  Our plan is to
> define a 'Versioned' class in Biobase. This class contains information
> about the version of Biobase in use when an object is created. If the
> object is 'serialized' (e.g., stored to disk) and retrieved at a later
> date, then the version information can be consulted to check that it
> is current, and can be used to update the instance to the current
> definition. More details to follow shortly...

This is precisely why I am asking.  I just went back to some data from 
about 1.5 years ago and was unhappy to find that many of the data 
structures in use at the time were not available at all, resulting in 
MANY calls looking like ma at ....@...

> 3. We plan to introduce a new method, updateClass, that can be
> used to update instances, either to their current version or to a
> different representation (e.g., from exprSet to ExpressionSet, but
> allowing more flexibility than 'setAs' methods might).

Sounds good.  I would think that the annotation packages might benefit 
from this as well, as often peoples' analyses were based on a particular 
set of annotations and switching would result in different results.

> 4. We do not have definite plans to remove methods, but I suspect
> there is room for limited housekeeping. Again, any changes at this
> level will occur sooner rather than later.

> 5. We are also developing additional classes. These will add to,
> rather than change, the existing repertoire. For instance, we are
> looking at an 'EmptyMatrix' class that contains information about
> dimensions and type, but not actual data. The idea is that these would
> be convenient placeholders for elements missing from assayData. They
> would look like matricies for many operations (is, dim, rownames, as,
> [ to other EmptyMatrix, etc.) but not contain numerical
> data.
> 
> Hope that helps. Look for more information about Versioned class
> shortly. Feedback most welcome!

I'll chime in if I can.  Thanks for the extensive answer.

Sean