[Biojava-l] Revised Parser

[Cox, Greg]

I understand your approach, but my preference is to keep them seperate.  I
think it keeps the code in the parser more understandable and I think it's
easier to understand the constructor call when you don't have to look up
what the boolean flag is.  

	That said, I'd like to either get this finished up, or decide to sit
on it until 1.2.  If merging both parsers is the way to go, I'll do that.  I
changed GenBank, EMBL, and SwissProt to keep all the parsers consistent.

	Greg

-----Original Message-----
From: Thomas Down [mailto:td2@sanger.ac.uk]
Sent: Thursday, February 08, 2001 6:36 AM
To: Cox, Greg
Cc: 'biojava-l@biojava.org'
Subject: Re: [Biojava-l] Revised Parser


On Wed, Feb 07, 2001 at 02:46:51PM -0500, Cox, Greg wrote:
> I'm revising the parsers to log a message when they come across a location
> they don't understand, and continue processing the file; instead of
throwing
> an exception and bombing out.  This will let us push off issues like the
> remote location problem.  I have a question for the list:
> 
> 	Should these revised parsers supplement or replace the current
> parsers?  I.e., is anyone's program going to break if bad files are
> partially processed instead of crashing the program?  A log message is
> written to System.err so it's not a silent failure.
> 
> 	If you'd like this to be a second parser instead of replacing the
> original, I'd appriciate a name for it; I can't come up with a good one.


Can I just suggest a third option: merge the two and add a boolean
property (`acceptRemoteFeatures'?)( to control behaviour.  Since
this is in GenbankProcessor (I presume...) you'll also need to add 
this property to GenbankProcessor.Factory and propogate it when
you construct processors.

This seems easier to me that having two separate classes, but
users really ought to be able to choose the behaviour they want.

Does this make sense?

    Thomas.