Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

unified FASTA/Q reader #222

Draft
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
1 participant
@luizirber
Copy link

commented Apr 14, 2019

(I set it as a draft PR to ask for comments before going further)

I want to have an unified one of opening a FASTA or FASTQ stream and parse it. The approach here uses new enums fastx::Reader and fastx::Record wrapping their fasta and fastq equivalents:

pub enum Reader<R: io::Read> {
    FASTA(fasta::Reader<R>),
    FASTQ(fastq::Reader<R>),
}

and then I implemented the FastqRead and FastaRead traits for the new fastx::Reader.
These are closed types (with enums) opposed to using open types (defining a trait and moving trait objects around). But I don't foresee this being adapted to other Record/Reader formats (especially GFF and BED, the other available in this crate).

I can't do this outside rust-bio because I use the Reader::new method to check it is a FASTA or FASTQ file, and then create the appropriate fasta::Reader or fastq::Reader struct:
https://github.com/rust-bio/rust-bio/pull/222/files#diff-392995b83cc786a5f370f588871b2f92R94
I had to change private fields in both structs, so I made the internals of the struct pub(crate) to let them be initialized in the crate (and I don't think the reader and line fields should be exposed in any way outside the crate).

I also made the read method in fastq::Reader more into what its counterpart in fasta::Reader is doing, avoiding clearing the line_buf field in the beginning (which defeated the purpose of setting it during the initialization in fastx::Reader::new().

TODO

  • more tests (I only copied two from the fasta and fastq modules)
  • finish the unimplemented! bits
  • error handling when creating a new Reader
  • maybe avoid reimplementing the Records iterator?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.