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

[Wolfgang Huber]

Hi Henrik, Benilton, Rafa,

who has the energy to do this and how does this concord with the work on
oligo? Is oligo intended to replace affy (and if yes, when)? If yes, I
am not sure it would be worthwhile to spend much time improving affy,
and we'd just maintain it with existing functionality for a few more
releases. If no, then of course, further developing affy is an important
project.

Best wishes
 Wolfgang

PS: Btw, one can argue that packages are objects, since they offer
aspects of modularity, encapsulation and inheritance. I agree with
Henrik that a design using the S4 object system could be more extensible
- but basic OOP ideas underlie the annotation package system, which in
addition offers good tools for distribution, versioning and documentation.

------------------------------------------------------------------
Wolfgang Huber  EBI/EMBL  Cambridge UK  http://www.ebi.ac.uk/huber



Henrik Bengtsson wrote:
> 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.
> 
> 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.
> 
> 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