You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@commons.apache.org by jo...@apache.org on 2012/09/28 00:53:47 UTC
svn commit: r1391258 -
/commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/Conversion.java
Author: joehni
Date: Thu Sep 27 22:53:46 2012
New Revision: 1391258
URL: http://svn.apache.org/viewvc?rev=1391258&view=rev
Log:
Use conversion tables for boolean arrays.
Modified:
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/Conversion.java
Modified: commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/Conversion.java
URL: http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/Conversion.java?rev=1391258&r1=1391257&r2=1391258&view=diff
==============================================================================
--- commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/Conversion.java (original)
+++ commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/Conversion.java Thu Sep 27 22:53:46 2012
@@ -18,7 +18,6 @@
*******************************************************************************/
package org.apache.commons.lang3;
-
/**
* <p>
* Static methods to convert a type into another, with endianness and bit ordering awareness.
@@ -56,6 +55,24 @@ package org.apache.commons.lang3;
*/
public class Conversion {
+
+ private static final boolean[] BOOL_FFFF = {false, false, false, false};
+ private static final boolean[] BOOL_TFFF = {true, false, false, false};
+ private static final boolean[] BOOL_FTFF = {false, true, false, false};
+ private static final boolean[] BOOL_TTFF = {true, true, false, false};
+ private static final boolean[] BOOL_FFTF = {false, false, true, false};
+ private static final boolean[] BOOL_TFTF = {true, false, true, false};
+ private static final boolean[] BOOL_FTTF = {false, true, true, false};
+ private static final boolean[] BOOL_TTTF = {true, true, true, false};
+ private static final boolean[] BOOL_FFFT = {false, false, false, true};
+ private static final boolean[] BOOL_TFFT = {true, false, false, true};
+ private static final boolean[] BOOL_FTFT = {false, true, false, true};
+ private static final boolean[] BOOL_TTFT = {true, true, false, true};
+ private static final boolean[] BOOL_FFTT = {false, false, true, true};
+ private static final boolean[] BOOL_TFTT = {true, false, true, true};
+ private static final boolean[] BOOL_FTTT = {false, true, true, true};
+ private static final boolean[] BOOL_TTTT = {true, true, true, true};
+
/**
* <p>
* Converts a hexadecimal digit into an int using the default (Lsb0) bit ordering.
@@ -184,50 +201,68 @@ public class Conversion {
* @return a boolean array with the binary representation of <code>hexDigit</code>
*/
public static boolean[] hexDigitToBools(char hexDigit) {
+ final boolean[] array;
switch (hexDigit) {
case '0':
- return new boolean[]{false, false, false, false};
+ array = BOOL_FFFF;
+ break;
case '1':
- return new boolean[]{true, false, false, false};
+ array = BOOL_TFFF;
+ break;
case '2':
- return new boolean[]{false, true, false, false};
+ array = BOOL_FTFF;
+ break;
case '3':
- return new boolean[]{true, true, false, false};
+ array = BOOL_TTFF;
+ break;
case '4':
- return new boolean[]{false, false, true, false};
+ array = BOOL_FFTF;
+ break;
case '5':
- return new boolean[]{true, false, true, false};
+ array = BOOL_TFTF;
+ break;
case '6':
- return new boolean[]{false, true, true, false};
+ array = BOOL_FTTF;
+ break;
case '7':
- return new boolean[]{true, true, true, false};
+ array = BOOL_TTTF;
+ break;
case '8':
- return new boolean[]{false, false, false, true};
+ array = BOOL_FFFT;
+ break;
case '9':
- return new boolean[]{true, false, false, true};
+ array = BOOL_TFFT;
+ break;
case 'a':// fall through
case 'A':
- return new boolean[]{false, true, false, true};
+ array = BOOL_FTFT;
+ break;
case 'b':// fall through
case 'B':
- return new boolean[]{true, true, false, true};
+ array = BOOL_TTFT;
+ break;
case 'c':// fall through
case 'C':
- return new boolean[]{false, false, true, true};
+ array = BOOL_FFTT;
+ break;
case 'd':// fall through
case 'D':
- return new boolean[]{true, false, true, true};
+ array = BOOL_TFTT;
+ break;
case 'e':// fall through
case 'E':
- return new boolean[]{false, true, true, true};
+ array = BOOL_FTTT;
+ break;
case 'f':// fall through
case 'F':
- return new boolean[]{true, true, true, true};
+ array = BOOL_TTTT;
+ break;
default:
throw new IllegalArgumentException("Cannot interpret '"
+ hexDigit
+ "' as a hexadecimal digit");
}
+ return array.clone();
}
/**
@@ -242,50 +277,68 @@ public class Conversion {
* @return a boolean array with the binary representation of <code>hexDigit</code>
*/
public static boolean[] hexDigitM0ToBools(char hexDigit) {
+ final boolean[] array;
switch (hexDigit) {
case '0':
- return new boolean[]{false, false, false, false};
+ array = BOOL_FFFF;
+ break;
case '1':
- return new boolean[]{false, false, false, true};
+ array = BOOL_FFFT;
+ break;
case '2':
- return new boolean[]{false, false, true, false};
+ array = BOOL_FFTF;
+ break;
case '3':
- return new boolean[]{false, false, true, true};
+ array = BOOL_FFTT;
+ break;
case '4':
- return new boolean[]{false, true, false, false};
+ array = BOOL_FTFF;
+ break;
case '5':
- return new boolean[]{false, true, false, true};
+ array = BOOL_FTFT;
+ break;
case '6':
- return new boolean[]{false, true, true, false};
+ array = BOOL_FTTF;
+ break;
case '7':
- return new boolean[]{false, true, true, true};
+ array = BOOL_FTTT;
+ break;
case '8':
- return new boolean[]{true, false, false, false};
+ array = BOOL_TFFF;
+ break;
case '9':
- return new boolean[]{true, false, false, true};
+ array = BOOL_TFFT;
+ break;
case 'a':// fall through
case 'A':
- return new boolean[]{true, false, true, false};
+ array = BOOL_TFTF;
+ break;
case 'b':// fall through
case 'B':
- return new boolean[]{true, false, true, true};
+ array = BOOL_TFTT;
+ break;
case 'c':// fall through
case 'C':
- return new boolean[]{true, true, false, false};
+ array = BOOL_TTFF;
+ break;
case 'd':// fall through
case 'D':
- return new boolean[]{true, true, false, true};
+ array = BOOL_TTFT;
+ break;
case 'e':// fall through
case 'E':
- return new boolean[]{true, true, true, false};
+ array = BOOL_TTTF;
+ break;
case 'f':// fall through
case 'F':
- return new boolean[]{true, true, true, true};
+ array = BOOL_TTTT;
+ break;
default:
throw new IllegalArgumentException("Cannot interpret '"
+ hexDigit
+ "' as a hexadecimal digit");
}
+ return array.clone();
}
/**
@@ -562,8 +615,7 @@ public class Conversion {
case 0xF:
return 'F';
default:
- throw new IllegalArgumentException("nibble value not between 0 and 15: "
- + nibble);
+ throw new IllegalArgumentException("nibble value not between 0 and 15: " + nibble);
}
}
@@ -619,8 +671,7 @@ public class Conversion {
case 0xF:
return 'F';
default:
- throw new IllegalArgumentException("nibble value not between 0 and 15: "
- + nibble);
+ throw new IllegalArgumentException("nibble value not between 0 and 15: " + nibble);
}
}
Re: svn commit: r1391258 - /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/Conversion.java
Posted by Benedikt Ritter <be...@gmail.com>.
2012/9/28 Jörg Schaible <Jo...@scalaris.com>:
> Hi Sebb,
>
> sebb wrote:
>
>> On 27 September 2012 23:53, <jo...@apache.org> wrote:
>>> Author: joehni
>>> Date: Thu Sep 27 22:53:46 2012
>>> New Revision: 1391258
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1391258&view=rev
>>> Log:
>>> Use conversion tables for boolean arrays.
>>
>> I think the previous code was much clearer.
>>
>> At first sight it now looks as though the static arrays are shared
>> (which would not be safe) but in fact they are cloned.
>
> At least I should have checked it with a profiler before. Don't we have a
> YourKit license for Apache somewhere?
YourKit has a licence for open source projects. Looks like you only
have to contact their sales by mail (using your @apache.org
account?!).
Benedikt
>
> - Jörg
>
>
> ---------------------------------------------------------------------
> 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
Re: svn commit: r1391258 - /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/Conversion.java
Posted by Jörg Schaible <jo...@gmx.de>.
Jörg Schaible wrote:
> Gary Gregory wrote:
>
>> On Wed, Oct 3, 2012 at 7:28 AM, Jörg Schaible <jo...@gmx.de>
>> wrote:
>>
>>> Jörg Schaible wrote:
>>>
>>> >
>>> > sebb wrote:
>>>
>>> [snip]
>>>
>>> >> I find the naming convention rather difficult to follow.
>>> >>
>>> >> For example, the letter 's' sometimes means 'array' and sometimes
>>> >> means 'string' Also M0 is not obvious as an abbreviation, nor is BeM0
>>> >
>>> > I am all open for better names, all *I* want to have is the
>>> functionality.
>>>
>>> Has anyone a better idea for the names?
>>>
>>
>> I would probably loose the plural to indicate an array.
>
> This is also ambiguous. Probably it would be better to use "array"
> directly. e.g.:
>
> - byteArrayToLong
> - longToByteArray
Done. Used "binary" for "boolArray" though, because that's what it meant.
>> I would expand M0 to Msb0 which itself is an acronym. Abbreviating an
>> acronym is to mysterious to me.
Done.
[snip]
>> I would use real examples in the Javadoc:
>>
>> * <p>
>> * (true, false, false, false) is converted as follow: '8' ...
>>
>> instead of:
>>
>> * <p>
>> * (1, 0, 0, 0) is converted as follow: '8' ...
>>
>> and use [ ] instead of ( ) to show an array
The example is for binary representation (which is modeled with boolean
arrays), therefore I kept the representation here.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: svn commit: r1391258 - /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/Conversion.java
Posted by Jörg Schaible <jo...@gmx.de>.
Gary Gregory wrote:
> On Wed, Oct 3, 2012 at 7:28 AM, Jörg Schaible <jo...@gmx.de>
> wrote:
>
>> Jörg Schaible wrote:
>>
>> >
>> > sebb wrote:
>>
>> [snip]
>>
>> >> I find the naming convention rather difficult to follow.
>> >>
>> >> For example, the letter 's' sometimes means 'array' and sometimes
>> >> means 'string' Also M0 is not obvious as an abbreviation, nor is BeM0
>> >
>> > I am all open for better names, all *I* want to have is the
>> functionality.
>>
>> Has anyone a better idea for the names?
>>
>
> I would probably loose the plural to indicate an array.
This is also ambiguous. Probably it would be better to use "array" directly.
e.g.:
- byteArrayToLong
- longToByteArray
> I would expand M0 to Msb0 which itself is an acronym. Abbreviating an
> acronym is to mysterious to me.
>
> So I'd end up with:
>
> boolBeMsb0ToHexDigit(boolean[] src)
>
> instead of:
>
> boolsBeM0ToHexDigit(boolean[] src)
Sounds reasonable.
> I would use real examples in the Javadoc:
>
> * <p>
> * (true, false, false, false) is converted as follow: '8' ...
>
> instead of:
>
> * <p>
> * (1, 0, 0, 0) is converted as follow: '8' ...
>
> and use [ ] instead of ( ) to show an array
OK.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: svn commit: r1391258 - /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/Conversion.java
Posted by Gary Gregory <ga...@gmail.com>.
Also note that we have org.apache.commons.*io*.EndianUtils which does not
do the same thing but it a good class name.
Gary
On Wed, Oct 3, 2012 at 10:51 AM, James Carman <ja...@carmanconsulting.com>wrote:
> Agreed. This is very cryptic, IMHO.
>
> On Wed, Oct 3, 2012 at 10:42 AM, Matt Benson <gu...@gmail.com> wrote:
> > Urgh; I find these method names rather painful. Why wouldn't we
> > simply provide endianness and bit ordering as enums, and parameterize
> > accordingly?
> >
> > Matt
> >
> > On Wed, Oct 3, 2012 at 9:07 AM, Gary Gregory <ga...@gmail.com>
> wrote:
> >> On Wed, Oct 3, 2012 at 7:28 AM, Jörg Schaible <jo...@gmx.de>
> wrote:
> >>
> >>> Jörg Schaible wrote:
> >>>
> >>> >
> >>> > sebb wrote:
> >>>
> >>> [snip]
> >>>
> >>> >> I find the naming convention rather difficult to follow.
> >>> >>
> >>> >> For example, the letter 's' sometimes means 'array' and sometimes
> means
> >>> >> 'string' Also M0 is not obvious as an abbreviation, nor is BeM0
> >>> >
> >>> > I am all open for better names, all *I* want to have is the
> >>> functionality.
> >>>
> >>> Has anyone a better idea for the names?
> >>>
> >>
> >> I would probably loose the plural to indicate an array.
> >>
> >> I would expand M0 to Msb0 which itself is an acronym. Abbreviating an
> >> acronym is to mysterious to me.
> >>
> >> So I'd end up with:
> >>
> >> boolBeMsb0ToHexDigit(boolean[] src)
> >>
> >> instead of:
> >>
> >> boolsBeM0ToHexDigit(boolean[] src)
> >>
> >> I would use real examples in the Javadoc:
> >>
> >> * <p>
> >> * (true, false, false, false) is converted as follow: '8' ...
> >>
> >> instead of:
> >>
> >> * <p>
> >> * (1, 0, 0, 0) is converted as follow: '8' ...
> >>
> >> and use [ ] instead of ( ) to show an array
> >>
> >> my 2c,
> >>
> >> Gary
> >>
> >>
> >>> - Jörg
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>
> >>>
> >>
> >>
> >> --
> >> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> >> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
> >> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
> >> Blog: http://garygregory.wordpress.com
> >> Home: http://garygregory.com/
> >> Tweet! http://twitter.com/GaryGregory
> >
> > ---------------------------------------------------------------------
> > 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
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: svn commit: r1391258 - /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/Conversion.java
Posted by James Carman <ja...@carmanconsulting.com>.
Agreed. This is very cryptic, IMHO.
On Wed, Oct 3, 2012 at 10:42 AM, Matt Benson <gu...@gmail.com> wrote:
> Urgh; I find these method names rather painful. Why wouldn't we
> simply provide endianness and bit ordering as enums, and parameterize
> accordingly?
>
> Matt
>
> On Wed, Oct 3, 2012 at 9:07 AM, Gary Gregory <ga...@gmail.com> wrote:
>> On Wed, Oct 3, 2012 at 7:28 AM, Jörg Schaible <jo...@gmx.de> wrote:
>>
>>> Jörg Schaible wrote:
>>>
>>> >
>>> > sebb wrote:
>>>
>>> [snip]
>>>
>>> >> I find the naming convention rather difficult to follow.
>>> >>
>>> >> For example, the letter 's' sometimes means 'array' and sometimes means
>>> >> 'string' Also M0 is not obvious as an abbreviation, nor is BeM0
>>> >
>>> > I am all open for better names, all *I* want to have is the
>>> functionality.
>>>
>>> Has anyone a better idea for the names?
>>>
>>
>> I would probably loose the plural to indicate an array.
>>
>> I would expand M0 to Msb0 which itself is an acronym. Abbreviating an
>> acronym is to mysterious to me.
>>
>> So I'd end up with:
>>
>> boolBeMsb0ToHexDigit(boolean[] src)
>>
>> instead of:
>>
>> boolsBeM0ToHexDigit(boolean[] src)
>>
>> I would use real examples in the Javadoc:
>>
>> * <p>
>> * (true, false, false, false) is converted as follow: '8' ...
>>
>> instead of:
>>
>> * <p>
>> * (1, 0, 0, 0) is converted as follow: '8' ...
>>
>> and use [ ] instead of ( ) to show an array
>>
>> my 2c,
>>
>> Gary
>>
>>
>>> - Jörg
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
>> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>
> ---------------------------------------------------------------------
> 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
Re: svn commit: r1391258 - /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/Conversion.java
Posted by Gary Gregory <ga...@gmail.com>.
I like the enum idea too.
G
On Wed, Oct 3, 2012 at 2:12 PM, Duncan Jones <du...@wortharead.com> wrote:
> On 3 October 2012 18:24, Jörg Schaible <jo...@gmx.de> wrote:
> > Matt Benson wrote:
> >
> >> Urgh; I find these method names rather painful. Why wouldn't we
> >> simply provide endianness and bit ordering as enums, and parameterize
> >> accordingly?
> >
> > Because the algorithm is different (although similar) every time and not
> all
> > combinations are implemented?
> >
> > Honestly, we would have to use in most cases a switch/case statement
> > internally anyway and either throw UnsupportedOperationException for the
> > unimplemented cases or someone would have to implement it ... ;-)
>
> I think the enum-based solution is much more elegant; the JavaDoc
> could then contain a table demonstrating which combinations are
> supported. The better of two evils, IMO.
>
> I'm always in favour of methods that can be easily understood from a
> cursory glance. It bodes well for easy code maintenance.
>
> Duncan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: svn commit: r1391258 - /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/Conversion.java
Posted by Duncan Jones <du...@wortharead.com>.
On 3 October 2012 18:24, Jörg Schaible <jo...@gmx.de> wrote:
> Matt Benson wrote:
>
>> Urgh; I find these method names rather painful. Why wouldn't we
>> simply provide endianness and bit ordering as enums, and parameterize
>> accordingly?
>
> Because the algorithm is different (although similar) every time and not all
> combinations are implemented?
>
> Honestly, we would have to use in most cases a switch/case statement
> internally anyway and either throw UnsupportedOperationException for the
> unimplemented cases or someone would have to implement it ... ;-)
I think the enum-based solution is much more elegant; the JavaDoc
could then contain a table demonstrating which combinations are
supported. The better of two evils, IMO.
I'm always in favour of methods that can be easily understood from a
cursory glance. It bodes well for easy code maintenance.
Duncan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: svn commit: r1391258 - /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/Conversion.java
Posted by Jörg Schaible <jo...@gmx.de>.
Matt Benson wrote:
> Urgh; I find these method names rather painful. Why wouldn't we
> simply provide endianness and bit ordering as enums, and parameterize
> accordingly?
Because the algorithm is different (although similar) every time and not all
combinations are implemented?
Honestly, we would have to use in most cases a switch/case statement
internally anyway and either throw UnsupportedOperationException for the
unimplemented cases or someone would have to implement it ... ;-)
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: svn commit: r1391258 - /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/Conversion.java
Posted by Matt Benson <gu...@gmail.com>.
Urgh; I find these method names rather painful. Why wouldn't we
simply provide endianness and bit ordering as enums, and parameterize
accordingly?
Matt
On Wed, Oct 3, 2012 at 9:07 AM, Gary Gregory <ga...@gmail.com> wrote:
> On Wed, Oct 3, 2012 at 7:28 AM, Jörg Schaible <jo...@gmx.de> wrote:
>
>> Jörg Schaible wrote:
>>
>> >
>> > sebb wrote:
>>
>> [snip]
>>
>> >> I find the naming convention rather difficult to follow.
>> >>
>> >> For example, the letter 's' sometimes means 'array' and sometimes means
>> >> 'string' Also M0 is not obvious as an abbreviation, nor is BeM0
>> >
>> > I am all open for better names, all *I* want to have is the
>> functionality.
>>
>> Has anyone a better idea for the names?
>>
>
> I would probably loose the plural to indicate an array.
>
> I would expand M0 to Msb0 which itself is an acronym. Abbreviating an
> acronym is to mysterious to me.
>
> So I'd end up with:
>
> boolBeMsb0ToHexDigit(boolean[] src)
>
> instead of:
>
> boolsBeM0ToHexDigit(boolean[] src)
>
> I would use real examples in the Javadoc:
>
> * <p>
> * (true, false, false, false) is converted as follow: '8' ...
>
> instead of:
>
> * <p>
> * (1, 0, 0, 0) is converted as follow: '8' ...
>
> and use [ ] instead of ( ) to show an array
>
> my 2c,
>
> Gary
>
>
>> - Jörg
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: svn commit: r1391258 - /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/Conversion.java
Posted by Gary Gregory <ga...@gmail.com>.
On Wed, Oct 3, 2012 at 7:28 AM, Jörg Schaible <jo...@gmx.de> wrote:
> Jörg Schaible wrote:
>
> >
> > sebb wrote:
>
> [snip]
>
> >> I find the naming convention rather difficult to follow.
> >>
> >> For example, the letter 's' sometimes means 'array' and sometimes means
> >> 'string' Also M0 is not obvious as an abbreviation, nor is BeM0
> >
> > I am all open for better names, all *I* want to have is the
> functionality.
>
> Has anyone a better idea for the names?
>
I would probably loose the plural to indicate an array.
I would expand M0 to Msb0 which itself is an acronym. Abbreviating an
acronym is to mysterious to me.
So I'd end up with:
boolBeMsb0ToHexDigit(boolean[] src)
instead of:
boolsBeM0ToHexDigit(boolean[] src)
I would use real examples in the Javadoc:
* <p>
* (true, false, false, false) is converted as follow: '8' ...
instead of:
* <p>
* (1, 0, 0, 0) is converted as follow: '8' ...
and use [ ] instead of ( ) to show an array
my 2c,
Gary
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: svn commit: r1391258 - /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/Conversion.java
Posted by Jörg Schaible <jo...@gmx.de>.
Jörg Schaible wrote:
>
> sebb wrote:
[snip]
>> I find the naming convention rather difficult to follow.
>>
>> For example, the letter 's' sometimes means 'array' and sometimes means
>> 'string' Also M0 is not obvious as an abbreviation, nor is BeM0
>
> I am all open for better names, all *I* want to have is the functionality.
Has anyone a better idea for the names?
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: svn commit: r1391258 - /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/Conversion.java
Posted by Jörg Schaible <jo...@gmx.de>.
sebb wrote:
> On 28 September 2012 18:47, Jörg Schaible <jo...@gmx.de> wrote:
>> sebb wrote:
>>
[snip]
>>> Unless there is a significant improvement across several Java
>>> versions, I'm -1 on the change as the code is now more obscure.
>>
>> Done.
>
> Thanks!
>
>> Any comment on replacing the standard hex representation (i.e. lower case
>> letters like JDK does)?
>
> 50/50
I tend to follow the JDK here.
> But it needs to be documented better; e.g. intToHexDigitM0 does not
> say whether output is upper or lower case.
>
> It's good that the code accepts either case on input.
>
> ==
>
> I find the naming convention rather difficult to follow.
>
> For example, the letter 's' sometimes means 'array' and sometimes means
> 'string' Also M0 is not obvious as an abbreviation, nor is BeM0
I am all open for better names, all *I* want to have is the functionality.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: svn commit: r1391258 - /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/Conversion.java
Posted by sebb <se...@gmail.com>.
On 28 September 2012 18:47, Jörg Schaible <jo...@gmx.de> wrote:
> sebb wrote:
>
>> On 28 September 2012 08:17, Jörg Schaible <Jo...@scalaris.com>
>> wrote:
>>> Hi Sebb,
>>>
>>> sebb wrote:
>>>
>>>> On 27 September 2012 23:53, <jo...@apache.org> wrote:
>>>>> Author: joehni
>>>>> Date: Thu Sep 27 22:53:46 2012
>>>>> New Revision: 1391258
>>>>>
>>>>> URL: http://svn.apache.org/viewvc?rev=1391258&view=rev
>>>>> Log:
>>>>> Use conversion tables for boolean arrays.
>>>>
>>>> I think the previous code was much clearer.
>>>>
>>>> At first sight it now looks as though the static arrays are shared
>>>> (which would not be safe) but in fact they are cloned.
>>>
>>> At least I should have checked it with a profiler before. Don't we have a
>>> YourKit license for Apache somewhere?
>>
>> Is a hoped for performance gain why you made the change?
>>
>> Unless there is a significant improvement across several Java
>> versions, I'm -1 on the change as the code is now more obscure.
>
> Done.
Thanks!
> Any comment on replacing the standard hex representation (i.e. lower case
> letters like JDK does)?
50/50
But it needs to be documented better; e.g. intToHexDigitM0 does not
say whether output is upper or lower case.
It's good that the code accepts either case on input.
==
I find the naming convention rather difficult to follow.
For example, the letter 's' sometimes means 'array' and sometimes means 'string'
Also M0 is not obvious as an abbreviation, nor is BeM0
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: svn commit: r1391258 - /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/Conversion.java
Posted by Jörg Schaible <jo...@gmx.de>.
Gary Gregory wrote:
> On Fri, Sep 28, 2012 at 1:47 PM, Jörg Schaible
> <jo...@gmx.de>wrote:
>
>> sebb wrote:
[snip]
>> > Unless there is a significant improvement across several Java
>> > versions, I'm -1 on the change as the code is now more obscure.
>>
>> Done.
>>
>> Any comment on replacing the standard hex representation (i.e. lower case
>> letters like JDK does)?
>
>
> While semantically the same, I wonder if changing the output style will
> surprise some users. I'm 50/50.
>
>
>> Or further usage of JDK functionality?
>>
>
> I think it has to be considered on a case by case basis if there are any
> side-effects like the one above.
This code is completely new for 3.2, so *now* is the time to decide ;-)
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: svn commit: r1391258 - /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/Conversion.java
Posted by Gary Gregory <ga...@gmail.com>.
On Sep 29, 2012, at 6:58, "Jörg Schaible" <jo...@gmx.de> wrote:
> Gary Gregory wrote:
>
>> On Fri, Sep 28, 2012 at 1:47 PM, Jörg Schaible
>> <jo...@gmx.de>wrote:
>>
>>> sebb wrote:
>
> [snip]
>
>>>> Unless there is a significant improvement across several Java
>>>> versions, I'm -1 on the change as the code is now more obscure.
>>>
>>> Done.
>>>
>>> Any comment on replacing the standard hex representation (i.e. lower case
>>> letters like JDK does)?
>>
>>
>> While semantically the same, I wonder if changing the output style will
>> surprise some users. I'm 50/50.
>>
>>
>>> Or further usage of JDK functionality?
>>>
>>
>> I think it has to be considered on a case by case basis if there are any
>> side-effects like the one above.
>
> This code is completely new for 3.2, so *now* is the time to decide ;-)
Well, we should just reuse the JRE then. The question should be
flipped: why should we /not/ reuse the JRE in this case?
G
>
> - Jörg
>
>
> ---------------------------------------------------------------------
> 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
Re: svn commit: r1391258 - /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/Conversion.java
Posted by Gary Gregory <ga...@gmail.com>.
On Fri, Sep 28, 2012 at 1:47 PM, Jörg Schaible <jo...@gmx.de>wrote:
> sebb wrote:
>
> > On 28 September 2012 08:17, Jörg Schaible <Jo...@scalaris.com>
> > wrote:
> >> Hi Sebb,
> >>
> >> sebb wrote:
> >>
> >>> On 27 September 2012 23:53, <jo...@apache.org> wrote:
> >>>> Author: joehni
> >>>> Date: Thu Sep 27 22:53:46 2012
> >>>> New Revision: 1391258
> >>>>
> >>>> URL: http://svn.apache.org/viewvc?rev=1391258&view=rev
> >>>> Log:
> >>>> Use conversion tables for boolean arrays.
> >>>
> >>> I think the previous code was much clearer.
> >>>
> >>> At first sight it now looks as though the static arrays are shared
> >>> (which would not be safe) but in fact they are cloned.
> >>
> >> At least I should have checked it with a profiler before. Don't we have
> a
> >> YourKit license for Apache somewhere?
> >
> > Is a hoped for performance gain why you made the change?
> >
> > Unless there is a significant improvement across several Java
> > versions, I'm -1 on the change as the code is now more obscure.
>
> Done.
>
> Any comment on replacing the standard hex representation (i.e. lower case
> letters like JDK does)?
While semantically the same, I wonder if changing the output style will
surprise some users. I'm 50/50.
> Or further usage of JDK functionality?
>
I think it has to be considered on a case by case basis if there are any
side-effects like the one above.
Gary
>
> - Jörg
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: svn commit: r1391258 - /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/Conversion.java
Posted by Jörg Schaible <jo...@gmx.de>.
sebb wrote:
> On 28 September 2012 08:17, Jörg Schaible <Jo...@scalaris.com>
> wrote:
>> Hi Sebb,
>>
>> sebb wrote:
>>
>>> On 27 September 2012 23:53, <jo...@apache.org> wrote:
>>>> Author: joehni
>>>> Date: Thu Sep 27 22:53:46 2012
>>>> New Revision: 1391258
>>>>
>>>> URL: http://svn.apache.org/viewvc?rev=1391258&view=rev
>>>> Log:
>>>> Use conversion tables for boolean arrays.
>>>
>>> I think the previous code was much clearer.
>>>
>>> At first sight it now looks as though the static arrays are shared
>>> (which would not be safe) but in fact they are cloned.
>>
>> At least I should have checked it with a profiler before. Don't we have a
>> YourKit license for Apache somewhere?
>
> Is a hoped for performance gain why you made the change?
>
> Unless there is a significant improvement across several Java
> versions, I'm -1 on the change as the code is now more obscure.
Done.
Any comment on replacing the standard hex representation (i.e. lower case
letters like JDK does)? Or further usage of JDK functionality?
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: svn commit: r1391258 - /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/Conversion.java
Posted by sebb <se...@gmail.com>.
On 28 September 2012 08:17, Jörg Schaible <Jo...@scalaris.com> wrote:
> Hi Sebb,
>
> sebb wrote:
>
>> On 27 September 2012 23:53, <jo...@apache.org> wrote:
>>> Author: joehni
>>> Date: Thu Sep 27 22:53:46 2012
>>> New Revision: 1391258
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1391258&view=rev
>>> Log:
>>> Use conversion tables for boolean arrays.
>>
>> I think the previous code was much clearer.
>>
>> At first sight it now looks as though the static arrays are shared
>> (which would not be safe) but in fact they are cloned.
>
> At least I should have checked it with a profiler before. Don't we have a
> YourKit license for Apache somewhere?
Is a hoped for performance gain why you made the change?
Unless there is a significant improvement across several Java
versions, I'm -1 on the change as the code is now more obscure.
> - Jörg
>
>
> ---------------------------------------------------------------------
> 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
Re: svn commit: r1391258 - /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/Conversion.java
Posted by Jörg Schaible <Jo...@scalaris.com>.
Hi Sebb,
sebb wrote:
> On 27 September 2012 23:53, <jo...@apache.org> wrote:
>> Author: joehni
>> Date: Thu Sep 27 22:53:46 2012
>> New Revision: 1391258
>>
>> URL: http://svn.apache.org/viewvc?rev=1391258&view=rev
>> Log:
>> Use conversion tables for boolean arrays.
>
> I think the previous code was much clearer.
>
> At first sight it now looks as though the static arrays are shared
> (which would not be safe) but in fact they are cloned.
At least I should have checked it with a profiler before. Don't we have a
YourKit license for Apache somewhere?
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: svn commit: r1391258 - /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/Conversion.java
Posted by sebb <se...@gmail.com>.
On 27 September 2012 23:53, <jo...@apache.org> wrote:
> Author: joehni
> Date: Thu Sep 27 22:53:46 2012
> New Revision: 1391258
>
> URL: http://svn.apache.org/viewvc?rev=1391258&view=rev
> Log:
> Use conversion tables for boolean arrays.
I think the previous code was much clearer.
At first sight it now looks as though the static arrays are shared
(which would not be safe) but in fact they are cloned.
> Modified:
> commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/Conversion.java
>
> Modified: commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/Conversion.java
> URL: http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/Conversion.java?rev=1391258&r1=1391257&r2=1391258&view=diff
> ==============================================================================
> --- commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/Conversion.java (original)
> +++ commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/Conversion.java Thu Sep 27 22:53:46 2012
> @@ -18,7 +18,6 @@
> *******************************************************************************/
> package org.apache.commons.lang3;
>
> -
> /**
> * <p>
> * Static methods to convert a type into another, with endianness and bit ordering awareness.
> @@ -56,6 +55,24 @@ package org.apache.commons.lang3;
> */
>
> public class Conversion {
> +
> + private static final boolean[] BOOL_FFFF = {false, false, false, false};
> + private static final boolean[] BOOL_TFFF = {true, false, false, false};
> + private static final boolean[] BOOL_FTFF = {false, true, false, false};
> + private static final boolean[] BOOL_TTFF = {true, true, false, false};
> + private static final boolean[] BOOL_FFTF = {false, false, true, false};
> + private static final boolean[] BOOL_TFTF = {true, false, true, false};
> + private static final boolean[] BOOL_FTTF = {false, true, true, false};
> + private static final boolean[] BOOL_TTTF = {true, true, true, false};
> + private static final boolean[] BOOL_FFFT = {false, false, false, true};
> + private static final boolean[] BOOL_TFFT = {true, false, false, true};
> + private static final boolean[] BOOL_FTFT = {false, true, false, true};
> + private static final boolean[] BOOL_TTFT = {true, true, false, true};
> + private static final boolean[] BOOL_FFTT = {false, false, true, true};
> + private static final boolean[] BOOL_TFTT = {true, false, true, true};
> + private static final boolean[] BOOL_FTTT = {false, true, true, true};
> + private static final boolean[] BOOL_TTTT = {true, true, true, true};
> +
> /**
> * <p>
> * Converts a hexadecimal digit into an int using the default (Lsb0) bit ordering.
> @@ -184,50 +201,68 @@ public class Conversion {
> * @return a boolean array with the binary representation of <code>hexDigit</code>
> */
> public static boolean[] hexDigitToBools(char hexDigit) {
> + final boolean[] array;
> switch (hexDigit) {
> case '0':
> - return new boolean[]{false, false, false, false};
> + array = BOOL_FFFF;
> + break;
> case '1':
> - return new boolean[]{true, false, false, false};
> + array = BOOL_TFFF;
> + break;
> case '2':
> - return new boolean[]{false, true, false, false};
> + array = BOOL_FTFF;
> + break;
> case '3':
> - return new boolean[]{true, true, false, false};
> + array = BOOL_TTFF;
> + break;
> case '4':
> - return new boolean[]{false, false, true, false};
> + array = BOOL_FFTF;
> + break;
> case '5':
> - return new boolean[]{true, false, true, false};
> + array = BOOL_TFTF;
> + break;
> case '6':
> - return new boolean[]{false, true, true, false};
> + array = BOOL_FTTF;
> + break;
> case '7':
> - return new boolean[]{true, true, true, false};
> + array = BOOL_TTTF;
> + break;
> case '8':
> - return new boolean[]{false, false, false, true};
> + array = BOOL_FFFT;
> + break;
> case '9':
> - return new boolean[]{true, false, false, true};
> + array = BOOL_TFFT;
> + break;
> case 'a':// fall through
> case 'A':
> - return new boolean[]{false, true, false, true};
> + array = BOOL_FTFT;
> + break;
> case 'b':// fall through
> case 'B':
> - return new boolean[]{true, true, false, true};
> + array = BOOL_TTFT;
> + break;
> case 'c':// fall through
> case 'C':
> - return new boolean[]{false, false, true, true};
> + array = BOOL_FFTT;
> + break;
> case 'd':// fall through
> case 'D':
> - return new boolean[]{true, false, true, true};
> + array = BOOL_TFTT;
> + break;
> case 'e':// fall through
> case 'E':
> - return new boolean[]{false, true, true, true};
> + array = BOOL_FTTT;
> + break;
> case 'f':// fall through
> case 'F':
> - return new boolean[]{true, true, true, true};
> + array = BOOL_TTTT;
> + break;
> default:
> throw new IllegalArgumentException("Cannot interpret '"
> + hexDigit
> + "' as a hexadecimal digit");
> }
> + return array.clone();
> }
>
> /**
> @@ -242,50 +277,68 @@ public class Conversion {
> * @return a boolean array with the binary representation of <code>hexDigit</code>
> */
> public static boolean[] hexDigitM0ToBools(char hexDigit) {
> + final boolean[] array;
> switch (hexDigit) {
> case '0':
> - return new boolean[]{false, false, false, false};
> + array = BOOL_FFFF;
> + break;
> case '1':
> - return new boolean[]{false, false, false, true};
> + array = BOOL_FFFT;
> + break;
> case '2':
> - return new boolean[]{false, false, true, false};
> + array = BOOL_FFTF;
> + break;
> case '3':
> - return new boolean[]{false, false, true, true};
> + array = BOOL_FFTT;
> + break;
> case '4':
> - return new boolean[]{false, true, false, false};
> + array = BOOL_FTFF;
> + break;
> case '5':
> - return new boolean[]{false, true, false, true};
> + array = BOOL_FTFT;
> + break;
> case '6':
> - return new boolean[]{false, true, true, false};
> + array = BOOL_FTTF;
> + break;
> case '7':
> - return new boolean[]{false, true, true, true};
> + array = BOOL_FTTT;
> + break;
> case '8':
> - return new boolean[]{true, false, false, false};
> + array = BOOL_TFFF;
> + break;
> case '9':
> - return new boolean[]{true, false, false, true};
> + array = BOOL_TFFT;
> + break;
> case 'a':// fall through
> case 'A':
> - return new boolean[]{true, false, true, false};
> + array = BOOL_TFTF;
> + break;
> case 'b':// fall through
> case 'B':
> - return new boolean[]{true, false, true, true};
> + array = BOOL_TFTT;
> + break;
> case 'c':// fall through
> case 'C':
> - return new boolean[]{true, true, false, false};
> + array = BOOL_TTFF;
> + break;
> case 'd':// fall through
> case 'D':
> - return new boolean[]{true, true, false, true};
> + array = BOOL_TTFT;
> + break;
> case 'e':// fall through
> case 'E':
> - return new boolean[]{true, true, true, false};
> + array = BOOL_TTTF;
> + break;
> case 'f':// fall through
> case 'F':
> - return new boolean[]{true, true, true, true};
> + array = BOOL_TTTT;
> + break;
> default:
> throw new IllegalArgumentException("Cannot interpret '"
> + hexDigit
> + "' as a hexadecimal digit");
> }
> + return array.clone();
> }
>
> /**
> @@ -562,8 +615,7 @@ public class Conversion {
> case 0xF:
> return 'F';
> default:
> - throw new IllegalArgumentException("nibble value not between 0 and 15: "
> - + nibble);
> + throw new IllegalArgumentException("nibble value not between 0 and 15: " + nibble);
> }
> }
>
> @@ -619,8 +671,7 @@ public class Conversion {
> case 0xF:
> return 'F';
> default:
> - throw new IllegalArgumentException("nibble value not between 0 and 15: "
> - + nibble);
> + throw new IllegalArgumentException("nibble value not between 0 and 15: " + nibble);
> }
> }
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org