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

[Wolfgang Huber]

Hi,

Rather than make up these new dimension objects in the CDF package, why 
not teach the affy:indices2xy function to reach into the appropriate CDF 
package and grab the *unexported*, existing i2xy function in order to do 
its thing, and the affy:xy2indices to grab the *unexported* xy2i 
function? Seems like the least intrusive way to do things, and more 
flexible.

  Best wishes
   Wolfgang


Kasper Daniel Hansen wrote:
> 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
> 
> _______________________________________________
> Bioc-devel at stat.math.ethz.ch mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel


-- 

Best wishes
   Wolfgang

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