Le 16/03/2012 13:33, Benedikt Ritter a écrit :
1. eliminate Token input parameter on nextToken() To me it looks like the token input parameter on nextToken() has the purpose of sparing object creation. How about a private field 'currentToken' that can be reused. No method parameters are better than one method parameter :)
This was the purpose of a ticket in JIRA to reduce memory allocations. In the light of the recent comments by Ted I'm curious to see if we can improve the performance without it.
2. add additional convenience methods Right now we have some methods for char handling like isEndOfFile(c). There are some methods missing like isDelimiter(c) or isEncapsulator(c). There is not much to say about this. I just think that isDelimiter(c) is slightly easier to understand than c == format.getDelimiter().
Be careful with the performance, I tried that and it was slower on my system.
3. eliminate input parameter c on readEscape (and rename it ?) Right now we have to pass an int to readEscape, but the method does not use that parameter. So why do we keep it? Also the method does not really "read" an escape. It assumes, that is is called after a "/" and then returns the delimiter for a letter.
I agree, and in general I find weird to give the current character to all the lexer methods.
4. Get rid of those nasty while(true) loops! There are several while true loops. It is really hard to see what is going on, because you can not exactly see when a loop ends. The worst example for this is encapsulatedTokenLexer. It has an outer while(true) loop with a nested inner loop, that may return a token, terminating both loops. I've tried to eliminate those while true loops, but without success.
I see nothing wrong with the loops, even the JDK in BufferedReader uses them. But if you find a faster alternative, go for it!
Emmanuel Bourg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
