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

[Kasper Daniel Hansen]

On Apr 11, 2007, at 11:55 AM, Seth Falcon wrote:

> Kasper Daniel Hansen <khansen at stat.Berkeley.EDU> writes:
>> How about putting them into a namespace and not export it (that might
>> be what Jim is thinking of). There is also the little thing that the
>> chip dimensions are also stored in the AffyBatch objects so now they
>> will be stored twice... this opens up some consistency things. But
>> then again, that will likely not be a problem.
>
> I think some of the fuss over the name space and masking issues is a
> bit misguided.  The whole point of name spaces is to allow packages to
> define symbols with the same name and give users and package
> developers a nice way to disambiguate.  At some point, we will need to
> grow up and use these mechanisms.
>
> I think should proceed as follows for the upcoming release:
>
> 1. Add deprecation warnings to xy2i and i2xy that are defined in the
>    cdf packages.  The message should tell users to use the functions
>    available in the affy package instead.
>
> 2. Add dimension info to the cdf packages.  This should have been
>    there in the first place.  To avoid further whining about name
>    space issues, I propose that we use a special name in the <chip>cdf
>    environment object.  Something like:
>
>        hgu95av2cdf[["CHIP_DIMS"]]
>
>    This avoids symbol collision at the package level and it seems
>    fairly safe to bet that there will not be any probe set IDs named
>    "CHIP_DIMS".

I would not do this. A major use of the cdf environment is to do what  
is essentially an apply over get(NAME, hgu95avcdf). I would envision  
that the addition of introducing a new "virtual" probeset would break  
a lot of existing code. I know I have quite a bit of existing code  
that would break if I needed to do something like "do this for all  
probesets, but start by removing one which is special".

What about just putting in a new data object in the CDF package, perhaps
   hgu95av2dim
This could be a vector or a list with nrow/ncol components.

Or perhaps to hint at other meta data (why not add stuff like species  
name and so on), and use
   hgu95av2chipmetadata
Then we could always subsequently add species names, etc.

To add complete confusion I would like to point out that from a  
certain perspective, metadata for the chip should not really be put  
into the CDF package. We already have several CDF packages for a  
given Affy chip, but the metadata is really consistent across these  
packages. A better place would be the probe packages since that info  
is supposed to be probeset-definition independent. Of course, using  
the probe package would be a major change, so I am not sure it is a  
practical solution (also, I believe some chips do not have a probe  
package).

Kasper

> 3. Teach the functions in affy to extract this info.
>
> 4. Consider whether we can also remove the duplication for AffyBatch
>    objects.  I haven't looked at how this is handled and it may be too
>    big of a change before the release.  The whole idea of OOP is that
>    we should be able to change this without messing up clients of our
>    code, but that requires things to have been done right in the first
>    place.
> Any strong objections?  I want to get this done asap.
>
> + seth
>
> -- 
> Seth Falcon | Computational Biology | Fred Hutchinson Cancer  
> Research Center
> http://bioconductor.org
>
> _______________________________________________
> Bioc-devel at stat.math.ethz.ch mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel