On Thu, May 19, 2011 at 5:14 AM, Stephen Colebourne <scolebou...@joda.org> wrote: > I doubt that the boxing will be a major performance problem. Moreover, > its one that will have to be solved for JDK 8 anyway (as Project > Lambda needs some kind of solution to enhance primitive/object > operations). >
I'd prefer to see this left alone. As Hen mentions on another thread, this isn't the biggest part of the lang APIs, and the consistency of a single Range type is appealing, especially if autoboxing woes are slated to be ameliorated in the not-too-distant future. HOWEVER, if we prefer to have the ability to optimize around these autoboxing complaints, why don't we add a level of inheritance to the CodePointTranslator taxonomy, wherein we place the "is this an applicable codepoint" check and delegate that to another interface? Now a specialized IntRange can be supplied after all, and can use a corresponding "CodepointInclusionPredicate" implementation to make the proper call. Optimizable, but works out of the box using autoboxing. > If the cast is a problem, why not have four versions of the operation > - Integer, Char, int and char? > That means that any optimisation for primitives can be handled > internally in a non-breaking way at a later date. > Sounds reasonable. Matt > Stephen > > > On 19 May 2011 05:47, Henri Yandell <flame...@gmail.com> wrote: >> *grumbles that they were ints and a previous RC candidate saw it >> change to Range* :) >> >> My bigger complaint is the explicit casting required to pass in chars: >> >> new UnicodeEscaper(Range.between(0, (int)'E')) ? >> >> Autoboxing doesn't seem to be able to turn a char into an Integer. >> >> Hen >> >> On Wed, May 18, 2011 at 6:53 AM, sebb <seb...@gmail.com> wrote: >>> I'm not happy with the boxing that is often needed to create a Range >>> of int or long, e.g. in StringEscapeUtils. >>> >>> Seems to me that the UnicodeEscaper and NumericEntityEscaper classes >>> should require ints rather than a Range, as this would cut down on the >>> boxing and unboxing that is currently needed, as well as the extra >>> code needed to provide comparisons etc. >>> >>> Or, there could be a specialised IntRange class using int to provide >>> the functionality. >>> >>> These changes are new to 3.0, so could be fixed now without backward >>> compat. problems. >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
