Thanks for the suggestions! Yes, writeMSData was my first go - but we have already a writeMSData function in mzR. I didn't want to make that a generic and implement it for the MS data objects in MSnbase, because I thought that calling a method `writeMSData,MSnExp` on an object the user knows to contain MS data might be too much (i.e. it would translate to "write the MS data from the MS data containing object to a file" while e.g. `write,MSnExp` would translate to "write the MS data containing object to a file"). I know is not the best reason for not using writeMSData -
Using export might be a good alternative - does also not interfere with the base::write. Would be nice if you could add that to BiocGenerics. thanks, jo On 09/19/2017 12:22 AM, Michael Lawrence wrote: > I was also about to suggest that we converge on export() but held back > because I was obviously biased. I also agree with making the target > explicit in the function name. It makes the intent of the code way > more obvious. > > On Mon, Sep 18, 2017 at 3:15 PM, Hervé Pagès <hpa...@fredhutch.org> wrote: >> Hi jo, >> >> At the moment probably not much to be gained unless you ran into >> some conflicts with other "write" methods defined in Bioconductor? >> >> Note that the arguments/signature of base::write() don't really >> help making it a clean generic functions (e.g. weird 'file' default, >> 'ncolumns' and 'sep' args that lack generality, no ellipsis). It seems >> to me that instead of trying to force write() into a generic, it might >> be easier/cleaner to define a method for the export() generic defined >> in rtracklayer. Maybe the discussion would be whether we should consider >> moving rtracklayer::export() to BiocGenerics? >> >> Finally, IMO there is nothing wrong in using specific write* names like >> writeMgfData, writeMSData, writeMzTabData, etc... It plays nicely with >> tab-completion, the user can use args() to quickly see all the args and >> their defaults, tab-completion also works on the arguments, and the user >> does not struggle in finding the man page (like s/he does sometimes >> with generic and methods, especially when those are defined in >> different packages). >> >> H. >> >> >> On 09/18/2017 10:21 AM, Rainer Johannes wrote: >>> Dear all! >>> >>> We are currently implementing mzML write support in `MSnbase` and did >>> implement a `write` method for the S4 objects in `MSnbase`. Now, the >>> question is whether it might not be better to define a `write` S4 >>> generic in `BiocGenerics`? >>> >>> >>> cheers, jo >>> >>> >>> >>> _______________________________________________ >>> Bioc-devel@r-project.org mailing list >>> >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel&d=DwICAg&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=10yPFYogq10f-iQf5EwJPYNuEYfi2q0m-34r6ELrqqQ&s=Ukn5OXjj6C3HDU7w5fAKxAeEAhG_9IC3llSKwkgMHCA&e= >>> >> -- >> 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: hpa...@fredhutch.org >> Phone: (206) 667-5791 >> Fax: (206) 667-1319 >> >> >> _______________________________________________ >> Bioc-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/bioc-devel _______________________________________________ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel