[Bioc-devel] RFC: xy2i and i2xy in *cdf packages

[Laurent Gautier]

2007/3/27, Henrik Bengtsson <hb at stat.berkeley.edu>:
> Hi,
>
> may I suggest to leave the package framework for "CDF package" an move
> to an object-oriented framework.  Define a class AffyCdf class that
> provide various access methods, e.g. indexToCoordinate() and
> coordinateToIndex().  Let subclass AffyCdfPackage extend AffyCdf such
> that its methods queries existing CDF package. Yet another class
> AffyCdfFile works directly towards CDF files.  AffyCdfDb works towards
> a data base, and so on.  All provide the same API.

In the object-oriented world, I think that this would make "AffyCdf"
an interface
that classes that AffyCdfFile would implement. I am not certain of how S4 offers
this kind of pattern.

What about having AffyCdfEnvironment rather than AffyCdfPackage ?
The idea is that Cdf definitions can exist inside and outside packages:
one may want to modify and try out a Cdf during an R session without
having to create / install / load the package.


> Migration: First step would be add an object of class AffyCdfPackage
> inside CDF packages, alternatively provide an additional way of
> loading CDF packages, such that there is an object, say with the same
> name as the "clean" chip type (CDF) name, e.g. 'hgu133a'.
> Then packages start using the AffyCdfPackage API (instead of accessing
> the CDF package environment directly), e.g. cdf <- hgu133a; idx <-
> coordinateToIndex(cdf, xy).  Both CDF package and AffyCdf object
> coexists for the price of one until all packages migrated.  When that
> is done, we have much more flexibility.

An intermediate step would be to have AffyCdfEnvironment inherit from
"environment",
and just define methods "coordinateToIndex" and inverse with an
"environment" signature.
This way one could both have an environment the old way for the
transition period, as
well as a class.
(OO in R is not quite like in Java, as methods work through "generic"
functions.)


L.

> With the above design it would be a piece of a cake to add a
> AffyCdfFile class to query CDF files on the fly using affxparser.
>
> /Henrik
>
>
> On 3/26/07, Wolfgang Huber <huber at ebi.ac.uk> wrote:
> > Hi Jim,
> >
> > I think Francesco's point is valid.
> > The chip design is independent of particular instances of data, and
> > includes the size of the chip. That the chip size resides in the data
> > container (AffyBatch) and all the other geometry annotation in the CDF
> > is incoherent. So, when the i2xy and xy2i functions go, can't we have
> > this annotation constant defined in the CDF package as well, so that you
> > can say, for example
> >
> >   xy <- indices2xy(i, cdf=hgu133acdf)
> >
> > Btw, the reason for putting the xy2i and i2xy functions into the CDF
> > packages was that these mapping functions are really a chip-geometry
> > annotation. It was a mistake to export them like that, though, they
> > should always only have been visible as hgu133acdf::xy2i() or
> > hgu133acdf$xy2i().
> >
> >   Best wishes
> >   Wolfgang
> >
> >
> > > Hi Francesco,
> > >
> > > Francesco Ferrari wrote:
> > >> PS: I know that no package uses these functions, but we use them to
> > >> produce data for another package (work is still in progress). We could
> > >> use indices2xy() and xy2indices() functions from affy package, but the
> > >> value for "nr" parameter is required.
> > >
> > > I'm confused by this. What does your package do with a cdf package that
> > > doesn't explicitly involve an AffyBatch?
> > >
> > > Best,
> > >
> > > Jim
> >
> > _______________________________________________
> > Bioc-devel at stat.math.ethz.ch mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >
>
> _______________________________________________
> Bioc-devel at stat.math.ethz.ch mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>