On Tue, Mar 11, 2014 at 3:33 PM, Hervé Pagès <hpages@fhcrc.org> wrote:

> On 03/11/2014 02:52 PM, Hervé Pagès wrote:
>
>> On 03/11/2014 09:57 AM, Valerie Obenchain wrote:
>>
>>> Hi Herve,
>>>
>>> On 03/10/2014 10:31 PM, Hervé Pagès wrote:
>>>
>>>> Hi Val,
>>>>
>>>> I think it would help understand the motivations behind this proposal
>>>> if you could give an example of a method where the user cannot supply
>>>> a file name but has to create a 'File' (or 'FileList') object first.
>>>> And how the file registry proposal below would help.
>>>> It looks like you have such an example in the GenomicFileViews package.
>>>> Do you think you could give more details?
>>>>
>>>
>>> The most recent motivating use case was in creating subclasses of
>>> GenomicFileViews objects (BamFileViews, BigWigFileViews, etc.) We wanted
>>> to have a general constructor, something like GenomicFileViews(), that
>>> would create the appropriate subclass. However to create the correct
>>> subclass we needed to know if the files were bam, bw, fasta etc.
>>> Recognition of the file type by extension would allow us to do this with
>>> no further input from the user.
>>>
>>
>> That helps, thanks!
>>
>> Having this kind of general constructor sounds like it could indeed be
>> useful. Would be an opportunity to put all these *File classes (the 22
>> RTLFile subclasses defined in rtracklayer and the 5 RsamtoolsFile
>> subclasses defined in Rsamtools) under the same umbrella (i.e. a parent
>> virtual class) and use the name of this virtual class (e.g. File) for
>> the general constructor.
>>
>> Allowing a registration mechanism to extend the knowledge of this File()
>> constructor is an implementation detail. I don't see a lot of benefit to
>> it. Only a package that implements a concrete File subclass would
>> actually need to register the new subclass. Sounds easy enough to ask
>> to whoever has commit access to the File() code to modify it. This
>> kind of update might also require adding the name of the package where
>> the new File subclass is implemented to the Depends/Imports/Suggests
>> of the package where File() lives, which is something that cannot be
>> done via a registration mechanism.
>>
>
> This clean-up of the *File jungle would also be a good opportunity to:
>
>   - Choose what we want to do with reference classes: use them for all
>     the *File classes or for none of them. (Right now, those defined
>     in Rsamtools are reference classes, and those defined in
>     rtracklayer are not.)
>
>   - Move the I/O functionality currently in rtracklayer to a
>     separate package. Based on the number of contributed packages I
>     reviewed so far that were trying to reinvent the wheel because
>     they had no idea that the I/O function they needed was actually
>     in rtracklayer, I'd like to advocate for using a package name
>     that makes it very clear that it's all about I/O.
>
>

I can see some benefit in renaming/reorganizing, but if they weren't able
to perform a simple google search for functionality, I don't think the name
of the package was the problem. "read gff bioconductor" returns rtracklayer
as the top hit.



>
> H.
>
>
>
>> H.
>>
>>
>>
>>> Val
>>>
>>>
>>>> Thanks,
>>>> H.
>>>>
>>>>
>>>> On 03/10/2014 08:46 PM, Valerie Obenchain wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I'm soliciting feedback on the idea of a general file 'registry' that
>>>>> would identify file types by their extensions. This is similar in
>>>>> spirit
>>>>> to FileForformat() in rtracklayer but a more general abstraction that
>>>>> could be used across packages. The goal is to allow a user to supply
>>>>> only file name(s) to a method instead of first creating a 'File' class
>>>>> such as BamFile, FaFile, BigWigFile etc.
>>>>>
>>>>> A first attempt at this is in the GenomicFileViews package
>>>>> (https://github.com/Bioconductor/GenomicFileViews). A registry
>>>>> (lookup)
>>>>> is created as an environment at load time:
>>>>>
>>>>> .fileTypeRegistry <- new.env(parent=emptyenv()
>>>>>
>>>>> Files are registered with an information triplet consisting of class,
>>>>> package and regular expression to identify the extension. In
>>>>> GenomicFileViews we register FaFileList, BamFileList and BigWigFileList
>>>>> but any 'File' class can be registered that has a constructor of the
>>>>> same name.
>>>>>
>>>>> .onLoad <- function(libname, pkgname)
>>>>> {
>>>>>      registerFileType("FaFileList", "Rsamtools", "\\.fa$")
>>>>>      registerFileType("FaFileList", "Rsamtools", "\\.fasta$")
>>>>>      registerFileType("BamFileList", "Rsamtools", "\\.bam$")
>>>>>      registerFileType("BigWigFileList", "rtracklayer", "\\.bw$")
>>>>> }
>>>>>
>>>>> The makeFileType() helper creates the appropriate class. This function
>>>>> is used behind the scenes to do the lookup and coerce to the correct
>>>>> 'File' class.
>>>>>
>>>>>  > makeFileType(c("foo.bam", "bar.bam"))
>>>>> BamFileList of length 2
>>>>> names(2): foo.bam bar.bam
>>>>>
>>>>> New types can be added at any time with registerFileType():
>>>>>
>>>>> registerFileType(NewClass, NewPackage, "\\.NewExtension$")
>>>>>
>>>>>
>>>>> Thoughts:
>>>>>
>>>>> (1) If this sounds generally useful where should it live? rtracklayer,
>>>>> GenomicFileViews or other? Alternatively it could be its own
>>>>> lightweight
>>>>> package (FileRegister) that creates the registry and provides the
>>>>> helpers. It would be up to the package authors that depend on
>>>>> FileRegister to register their own files types at load time.
>>>>>
>>>>> (2) To avoid potential ambiguities maybe searching should be by regex
>>>>> and package name. Still a work in progress.
>>>>>
>>>>>
>>>>> Valerie
>>>>>
>>>>> _______________________________________________
>>>>> Bioc-devel@r-project.org mailing list
>>>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>>>>
>>>>
>>>>
>>>
>>>
>>
> --
> Hervé Pagès
>
> Program in Computational Biology
> Division of Public Health Sciences
> Fred Hutchinson Cancer Research Center
> 1100 Fairview Ave. N, M1-B514
> P.O. Box 19024
> Seattle, WA 98109-1024
>
> E-mail: hpages@fhcrc.org
> Phone:  (206) 667-5791
> Fax:    (206) 667-1319
>

	[[alternative HTML version deleted]]

