guava
guava copied to clipboard
google
Add Converter for booleans
Original issue created by [email protected] on 2014-03-31 at 07:36 PM
All of the primitives have stock Converter implementations, except for booleans. Such a converter should be added.
Original comment posted by [email protected] on 2014-03-31 at 07:41 PM
This question came up internally, so I'm just copying what Kevin wrote earlier:
"I think Boolean is legitimately a special case, because of the greater variety of different rules different users will want or even expect, plus the fact that it's pretty easy to hand-roll whatever exact rule you want. If we do add Booleans.stringConverter() (which we're not exactly fundamentally opposed to, it's just that even things this small take work), I think the best thing it can do is convert only the exact strings "true" and "false", nothing else. Any surprises will just prompt users to write the particular converter they really want (any two of which I suspect will be unlikely to be exactly the same)."
I also looked a handful of Converter<String, Boolean> implementations that have been checked into the Google code base and found: 4 use Boolean.valueOf() or parseBoolean() 2 convert "", "no", "false", "0", "null" (ignoring case) to false 1 converts "Yes" (ignoring case) to true, everything else converst to false
What semantics would you expect Booleans.stringConverter() to have?
Status: Research
Labels: Type-Addition, Package-Primitives
Original comment posted by [email protected] on 2014-03-31 at 08:37 PM
I would expect the same semantics as Boolean.valueOf() / parseBoolean(); my implementation uses the latter.
I agree that there are a lot of different ways to represent a boolean, but those methods are baked into Java and thus are a "standard" conversion in my opinion. So it would make sense to have a stock converter for the standard behavior, and then non-standard behavior can be covered by custom converters.
+1 for this. It's surprising to have stringConverter for every primitive except Booleans. For symmetry's sake it makes sense there should be one for Booleans, and that it should have the same .toString() / parseX() implementation as the others. I actually spent a while looking for it, because I was convinced that it must exist and I was just missing it.
Most users will say "well, logically we figure it should use Boolean.valueOf()". But how many of these users could tell you off the top of their heads what Boolean.valueOf() does? What does it do for null? "FALSE"? "tRuE"?
That there is an expectation for it to call method X does not mean that people actually expect that behavior, and it also doesn't mean it's the safest behavior.
At this point I still stand by my previous points:
- Boolean is a special case compared to the others because there is a much greater variety of behaviors users might want, and a much greater variety of behaviors they might assume.
- It's also special because it's easy to hand-roll the precise behavior you want, which will leave your readers actually knowing what is going on with no surprises.
- If this converter does exist, the most conservative behavior is to reject any input but "true" and "false". 95%+ of usages will probably be just fine with that, and the rest, who see an exception, will be prompted to decide what they want. No surprises can lurk undetected.
Btw, as reasons to add a library feature go, for us "symmetry" ranks pretty close to dead last. It's one of the things that's very different about Guava from many other libraries. Every feature has to pay for itself, not just seem like it is rounding out a complete set of something.
I agree Boolean is more special than Integer, but I think the same arguments apply to Float, Double, and Enum. Does Doubles.stringConverter preserve all digits of precision? Does it use scientific notation or lots of zeros? What does it do for null? Same for Enums.stringConverter - is it case-sensitive when reading?
You're right to shutdown my symmetry argument, bloated common libs are creaky.
A better argument would be that all of these Primitives.stringConverters are useful for cases where the user hasn't thought a ton about edge case behavior - they're looking for functional defaults. If a user cares about edge-case behavior, they're going to make their own. Booleans are very common, it would be nice to have a functional default.
Ned Twigg Lead Software Architect, DiffPlug LLC 949-264-3433 340 S Lemon Ave #3433, Walnut, CA 91789
On Wed, Nov 5, 2014 at 8:12 AM, kevinb9n [email protected] wrote:
Most users will say "well, logically we figure it should use Boolean.valueOf()". But how many of these users could tell you off the top of their heads what Boolean.valueOf() does? What does it do for null? "FALSE"? "tRuE"?
That there is an expectation for it to call method X does not mean that people actually expect that behavior, and it also doesn't mean it's the safest behavior.
At this point I still stand by my previous points:
Boolean is a special case compared to the others because there is much greater variety of behaviors users might want, and much greater variety of behaviors they might assume. 2.
It's also special because it's easy to hand-roll the precise behavior you want, which will leave your readers actually knowing what is going on with no surprises. 3.
If this converter does exist, the most conservative behavior is to reject any input but "true" and "false". 95%+ of usages will probably be just fine with that, and the rest, who see an exception, will be prompted to decide what they want. No surprises can lurk undetected.
Btw, as reasons to add a library feature go, for us "symmetry" ranks pretty close to dead last. It's one of the things that's very different about Guava from many other libraries. Every feature has to pay for itself, not just seem like it is rounding out a complete set of something.
— Reply to this email directly or view it on GitHub https://github.com/google/guava/issues/1710#issuecomment-61832350.
