Would it be better to let the user (registerer) specify a function, which could be a simple class constructor or something more complex in cases where that would be useful?
This could allow the concept to generalize to other things, such as databases that might need some startup machinery called before they are actually useful to the user. This would also deal with Michael's point about package/where since functions have their own "where" information. Unless I'm missing some other intent for specifying a specific package? ~G On Tue, Mar 11, 2014 at 5:59 AM, Michael Lawrence <lawrence.mich...@gene.com > wrote: > rtracklayer essentially has this, although registration is implicit through > extension of RTLFile or RsamtoolsFile, and the extension is taken from the > class name. There is a BigWigFile, corresponding to ".bigwig", and that is > extended by BWFile to support the ".bw" extension. The expectation is that > other packages would extend RTLFile to implictly register handlers. I'm > not sure there is a use case for generalization, but this proposal makes > registration more explicit, which is probably a good thing. rtracklayer was > just piggy backing on S4 registration. > > I'm a little bit confused by the use of Lists rather than individual File > objects. Are you also proposing that all RTLFiles would need a > corresponding List, and that there would need to be an RTLFileList method > for the various generics? > > It may not be necessary to specify the package name. There should be an > environment (where) argument that defaults to topenv(parent.frame()), and > that should suffice. > > Michael > > > On Mon, Mar 10, 2014 at 8:46 PM, Valerie Obenchain <voben...@fhcrc.org > >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 > > > > [[alternative HTML version deleted]] > > _______________________________________________ > Bioc-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/bioc-devel > -- Gabriel Becker Graduate Student Statistics Department University of California, Davis [[alternative HTML version deleted]] _______________________________________________ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
