You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Emmanuel Bourg <sm...@lfjr.net> on 2004/06/13 14:58:27 UTC
[configuration] Numbers conversions
Hello, I'm considering a change to improve the flexibility of
[configuration] with regard to the numbers conversions. Currently any
Number put in a configuration can't be retrieved as another Number type,
for example:
config.setProperty("number", new Byte(123));
config.getInteger("number");
throws a ClassCastException, but:
config.setProperty("number", "123");
config.getInteger("number");
works fine.
The change consists in testing in the getXXX methods if the object
retrieved is a Number and call the Number.xxxValue() method to convert
it to the appropriate type. I'm attaching a patch and a test case to
illustrate this.
What do you think ?
Emmanuel Bourg
RE: [configuration] Numbers conversions
Posted by Eric Pugh <ep...@upstate.com>.
I can understand your concern about both the storing of the property as a
string instead of as an object. If we are going to do that, then
setProperty should take (string,string)!
When you do this:
BigDecimal number = new BigDecimal((String) value);
return new Byte(number.byteValue())
does BigDecimal do all the conversion for you? What about this:
BigInteger number = new BigInteger ((String) value);
return new Integer(number.intValue())
Copied from the JavaDocs is this:
intValue
public int intValue()
Converts this BigInteger to an int. This conversion is analogous to a
narrowing primitive conversion from long to int as defined in the Java
Language Specification: if this BigInteger is too big to fit in an int, only
the low-order 32 bits are returned. Note that this conversion can lose
information about the overall magnitude of the BigInteger value as well as
return a result with the opposite sign.
Specified by:
intValue in class Number
Returns:
this BigInteger converted to an int.
It seems to me that the risk of returning something with an opposite sign,
plus the fact that this is all a bit hairy means that we should throw an
Exception and leave it up to the application to decide what the right thing
is to do, versus trying to guess it. Eventually, in post 1.0, we could have
this be a pluggable Strategy that decided what to do, allowing users to
change it from a "throw Exception" to a "try and convert" strategy.
Eric
> -----Original Message-----
> From: Emmanuel Bourg [mailto:ebourg@micropole-univers.com]
> Sent: Monday, June 14, 2004 3:45 PM
> To: Jakarta Commons Developers List
> Subject: Re: [configuration] Numbers conversions
>
>
> Well I admit there is one inconsistency with the change I suggest, while
> the following code would work:
>
> config.setProperty("number", new Integer(65535));
> config.getByte("number");
>
> this one will fail and throw an exception:
>
> config.setProperty("number", "65535");
> config.getByte("number");
>
> I see 2 solutions to solve this, we can either:
>
> - serialize the Number to a String on calling setProperty, then it will
> be automatically parsed. I'm a bit reluctant to change the object stored
> though, and this will not work if the object is already stored as a
> Number (if we read a JNDIConfiguration for example). The serialization
> could also occur in the getXXX method, something like this:
>
> if (value instanceof Number) {
> String s = value.toString();
> return new Byte(s);
> }
>
> - downcast the number stored as a string by creating a BigDecimal and
> calling Number.xxxValue() instead of parsing the String through the
> concrete Number class. For example :
>
> BigDecimal number = new BigDecimal((String) value);
> return new Byte(number.byteValue());
>
> instead of
>
> Byte b = new Byte((String) value);
> return b;
>
>
> Alternatively we could also detect the loss of information and log a
> warning.
>
> Emmanuel Bourg
>
>
>
> Eric Pugh wrote:
>
> > Re: [configuration] Numbers conversionsOh... Ick... I guess that
> > while
> > that is consistent with downcasting in Java, I don't think that it is
> > consistent with how the Commons Configuration API "feels".. The api
> > does a
> > lot to try and convert things for the user..
> >
> > Do you have a real resistence to the idea of throwing an exception? If
> > you
> > like, apply your changes, and then I'll do it.. It just seems to make
> > more
> > sense...
> >
> > Eric
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [configuration] Numbers conversions
Posted by Emmanuel Bourg <eb...@micropole-univers.com>.
Well I admit there is one inconsistency with the change I suggest, while
the following code would work:
config.setProperty("number", new Integer(65535));
config.getByte("number");
this one will fail and throw an exception:
config.setProperty("number", "65535");
config.getByte("number");
I see 2 solutions to solve this, we can either:
- serialize the Number to a String on calling setProperty, then it will
be automatically parsed. I'm a bit reluctant to change the object stored
though, and this will not work if the object is already stored as a
Number (if we read a JNDIConfiguration for example). The serialization
could also occur in the getXXX method, something like this:
if (value instanceof Number) {
String s = value.toString();
return new Byte(s);
}
- downcast the number stored as a string by creating a BigDecimal and
calling Number.xxxValue() instead of parsing the String through the
concrete Number class. For example :
BigDecimal number = new BigDecimal((String) value);
return new Byte(number.byteValue());
instead of
Byte b = new Byte((String) value);
return b;
Alternatively we could also detect the loss of information and log a
warning.
Emmanuel Bourg
Eric Pugh wrote:
> Re: [configuration] Numbers conversionsOh... Ick... I guess that
> while
> that is consistent with downcasting in Java, I don't think that it is
> consistent with how the Commons Configuration API "feels".. The api
> does a
> lot to try and convert things for the user..
>
> Do you have a real resistence to the idea of throwing an exception? If
> you
> like, apply your changes, and then I'll do it.. It just seems to make
> more
> sense...
>
> Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [configuration] Numbers conversions
Posted by Eric Pugh <ep...@upstate.com>.
Re: [configuration] Numbers conversionsOh... Ick... I guess that while
that is consistent with downcasting in Java, I don't think that it is
consistent with how the Commons Configuration API "feels".. The api does a
lot to try and convert things for the user..
Do you have a real resistence to the idea of throwing an exception? If you
like, apply your changes, and then I'll do it.. It just seems to make more
sense...
Eric
-----Original Message-----
From: Emmanuel Bourg [mailto:smanux@lfjr.net]
Sent: Sunday, June 13, 2004 7:00 PM
To: Jakarta Commons Developers List
Subject: Re: [configuration] Numbers conversions
Eric Pugh wrote:
> If I put in a really big number and then try to retrieve it as an
Integer,
> getting back -1 would be a rather shock! I think I would rather hit an
> exception instead, thereby clueing me in that I couldn't downcast...
Actually it's just consistent with the downcasting in Java:
( (int) Long.MAX_VALUE ) == -1
Emmanuel Bourg
Re: [configuration] Numbers conversions
Posted by Emmanuel Bourg <sm...@lfjr.net>.
Eric Pugh wrote:
> If I put in a really big number and then try to retrieve it as an Integer,
> getting back -1 would be a rather shock! I think I would rather hit an
> exception instead, thereby clueing me in that I couldn't downcast...
Actually it's just consistent with the downcasting in Java:
( (int) Long.MAX_VALUE ) == -1
Emmanuel Bourg
RE: [configuration] Numbers conversions
Posted by Eric Pugh <ep...@upstate.com>.
[configuration] Numbers conversionsI like the upcasting stuff! However
shouldn't these unit tests throw the ConversionRuntimeException:
// downcasting
+ config.setProperty("number", new Long(Long.MAX_VALUE));
+ assertEquals("Long to Integer", -1, config.getInt("number"));
+ assertEquals("Long to Short", -1, config.getShort("number"));
+ assertEquals("Long to Byte", -1, config.getByte("number"));
If I put in a really big number and then try to retrieve it as an Integer,
getting back -1 would be a rather shock! I think I would rather hit an
exception instead, thereby clueing me in that I couldn't downcast...
Eric
-----Original Message-----
From: Emmanuel Bourg [mailto:smanux@lfjr.net]
Sent: Sunday, June 13, 2004 2:58 PM
To: Jakarta Commons Developers List
Subject: [configuration] Numbers conversions
Hello, I'm considering a change to improve the flexibility of
[configuration] with regard to the numbers conversions. Currently any
Number put in a configuration can't be retrieved as another Number type,
for example:
config.setProperty("number", new Byte(123));
config.getInteger("number");
throws a ClassCastException, but:
config.setProperty("number", "123");
config.getInteger("number");
works fine.
The change consists in testing in the getXXX methods if the object
retrieved is a Number and call the Number.xxxValue() method to convert
it to the appropriate type. I'm attaching a patch and a test case to
illustrate this.
What do you think ?
Emmanuel Bourg