On Mon, Mar 7, 2011 at 10:05 PM, Henri Yandell <flame...@gmail.com> wrote: > On Sat, Mar 5, 2011 at 8:46 AM, Oliver Heger > <oliver.he...@oliver-heger.de> wrote: >> Two minor points from my side: >> > >> - Just a proposal: There are some translators in the new translate package >> which can be configured with a range of the codes to be processed. Would it >> make sense to use the Range class for this purpose? Then configuration could >> be more flexible (because multiple ranges could be specified), and there >> would probably be less duplicate code for checking the ranges. > > Very interesting. > > Also makes me wonder if Range should support the notion of > Range.above, Range.below and Range.outside in addition to > Range.between and Range.is. That change the API from: > > UnicodeEscaper.between(x, y) > > to: > > new UnicodeEscaper(Range.between(x,y)) > new UnicodeEscaper(Range.above(y)) > new UnicodeEscaper(Range.below(x)) > new UnicodeEscaper(Range.outsideOf(x,y)) > > For the translators; sounds great. I'm trying to remember if I hit > problems introducing the feature of either an open-ended Range, or an > inverted Range. Looking at LANG-551, it looks like I tried to > introduce the inverted Range notion (outsideOf) so that I could merge > in CharRange, and it never really worked. > > Worth trying again I think.
I've begun by implementing the code in the translators as a new CodepointRange. Stunningly (actually I was a bit surprised) I've rewritten CharRange :) So at a minimum I think: a) CharRange should be updated for codepoints. b) Translators should use CharRange. I also tried to update Range to support the necessary features, and the two APIs don't fit too well together. I'm going to go ahead and do a) and b); then ponder the CharRange into Range question again. Hen --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
