[Biojava-dev] Parser backwards compatibility

[P. Troshin]

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