[Biojava-dev] Parser backwards compatibility

[David Felty]

Michael Heuer wrote:
> Open source projects should projects should provide room for
> both evolutionary and revolutionary changes

Thanks for all the info, very useful!

P. Troshin wrote:
> I think you just need to make a common entry point for them.
> E.g a factory class which would contain functions to
> instantiate various parsers.

So what you're looking for is something like this?
FastaParser fasta = ParserFactory.fasta("example.fasta");
FastqParser fastq = ParserFactory.fastq("example.fastq");

Scooter Willis wrote:
> Can you give some examples of what you are trying to do for
> the common set of interfaces?

I gave this example in my proposal at
http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/dfelt/2001

for (BasicSequence seq : SeqIO.parse(inStream, SeqFormat.FASTA) {
    System.out.println(seq.getSequenceAsString());
}

But I think Troshin's idea would be easier to implement, given
the current BioJava parsers.
 On Apr 13, 2012 1:31 PM, "P. Troshin" <to.petr at gmail.com> wrote:

> Hi David,
>
> > In order to fit BioJava's parsers into a shared API, I would like to
> > wrap them under a common set of interfaces.
>
> I think you just need to make a common entry point for them. E.g. a
> factory class which would contain functions to instantiate various
> parsers.
> You only need a common interface for the same parsers, e.g. Fasta
> parsers. However, I'd be inclined to converge all Fasta parsers in
> BioJava to one parser. So I am not sure you'd need a common interface
> in the end.
>
> >However, I foresee that
> > some of the parsers will resist being wrapped, and will need to either
> > be modified or rewritten.
>
> You'll need to choose the best parser and implement features that a
> lacking from it. Other parsers then can be retired.
>
>
> >However, this would mean that two different
> > copies of the same parsers would exist in BioJava, which I think is
> > kind of ugly.
>
> Yes, that would be scary for the languages like Perl or Python, but
> Java is compiled language, so you'll see most of the problems as
> compilation errors. You will also need to write unit tests for
> existing parsers and then for your new parser to make sure that
> rewrite were successful.
>
> >However, this would mean that two different
> > copies of the same parsers would exist in BioJava, which I think is
> > kind of ugly.
>
> The whole idea of this project is to get rid of this ugliness, and
> provide a streamline API for the users as well as the powerful
> parsers.
>
> Hope that helps.
> Regards,
> Peter
>
>
> On 13 April 2012 14:47, David Felty <davfelty at gmail.com> wrote:
> > In order to fit BioJava's parsers into a shared API, I would like to
> > wrap them under a common set of interfaces. However, I foresee that
> > some of the parsers will resist being wrapped, and will need to either
> > be modified or rewritten. So my question is, should I keep the
> > original versions these problematic parsers around for backwards
> > compatibility, or can I freely modify them to fit into the new API?
> > I'm afraid that the latter would break existing code, so I'm more
> > inclined to do the former. However, this would mean that two different
> > copies of the same parsers would exist in BioJava, which I think is
> > kind of ugly. Any thoughts?
> >
> > Thanks,
> > David
> > _______________________________________________
> > biojava-dev mailing list
> > biojava-dev at lists.open-bio.org
> > http://lists.open-bio.org/mailman/listinfo/biojava-dev
>