[Bioc-devel] RFC: xy2i and i2xy in *cdf packages
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