On Tue, 27 Mar 2007 13:43:31 +0200, Josip Rodin <[EMAIL PROTECTED]> said:
> We strayed from the real point here... the point is that these > internal variables are completely irrelevant to the voters and > should be avoided. The program can detect the line "[ ... ] Option > name" just as easily as it can detect "[ ... ] specialstring: Option > name". This by itself is not justification enough. The fact that the ballot provides redundant information that is irrelevant to the users, but in turn eases parsing of potentially MTA mangled ballots seems like a win. Given that ballots can be word wrapped, can have common leading text, might have words that are damaged by MUA's not encoding a non-ascii word identically; it makes sense to increase the robustness of the parser by giving it a well known, unique prefix. Also, the current implementation optimizes for potential re-sorted ballot lines by using the Choice N string to determine which index in the options array the ranking is referring to; and I do not see enough of a reason to refactor the code. So, if some one can demonstrate to me that the parser will not become less robust, and that the new code is equally resilient to MUA mangling of ballots, and that the increased complexity of code does not impact future maintenance, and that all this effort has a tangible benefit --- I'll consider reevaluating this design decision. manoj -- O'Toole's commentary on Murphy's Law: Murphy was an optimist. Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]