[Bioc-devel] Couple of eSet questions

[Seth Falcon]

On  3 Feb 2006, stvjc at channing.harvard.edu wrote:
> it sounds to me as if we are finding some use cases, and that
> we want to extend eSet to cope with those that have well-defined
> requirements.  all we know about assayData at present is that
> it is either a list or an environment.  for twochannel data
> we may want to define a specific extension of listOrEnv (i think
> this is possible) that has guaranteed structure and names.
> for data with standard errors we might have to do likewise.
>
> but i would say that part of the intention of the eSet is to
> require the developer always to allow an environment representation
> for the assayData.  the validity criteria can impose restrictions
> on this environment.

Respectfully, I think I disagree.  I would like to have the use cases
drive the design of specific subclasses of an eSet-like class where
the structure is expressed as part of the class definition
(e.g. exprSet should have an exprs slot, not a named element of an
env).

Pushing the definition of the structure to the validity function makes
the actual structure harder to see (IMO) and I'm concerned that it
will make extensions which otherwise would be trivial subclasses,
tricky.  I guess a part of my objection is that it feels as though we
will be implementing our own mini class system where slots are the
named elements of an env.

A compelling argument for forcing the actual data to be in an
environment is to avoid copying.  

> eSet itself does not need to solve the two channel or
> error-available problems at once.  it should be extended to do so,
> with explicit use cases stated.

Yes, I'm just not convinced that eSet has any business having actual
data slots; those are the domain of its subclasses.

Putting aside my perhaps ideological objections, maybe a compromise is
to work on some of the concrete subclasses (two-channel data being one
good example) and factor out the common elements as the evolve.  

+ seth