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

Seth Falcon sfalcon at fhcrc.org
Wed Apr 11 20:55:54 CEST 2007


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".

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



More information about the Bioc-devel mailing list