commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@gmail.com>
Subject Re: [LANG] unnecessary boxing in StringEscapeUtils etc.
Date Sun, 19 Jun 2011 16:03:48 GMT
On Thu, May 19, 2011 at 5:14 AM, Stephen Colebourne
<scolebourne@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 <flamefew@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 <sebbaz@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-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message