• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Boolean.getBoolean() is confusing

 
Ranch Hand
Posts: 1873
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi all,

In Boolean class the method getBoolean() is confusing as its name and what it does is not easy to relate.

Am I right?

Regards
Maulin
 
Ranch Hand
Posts: 808
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Use it to test the existence and value of a system property. Feed it the results of a getProperty method call and you'll get the value true if the property exists and if its value is true.

More useful than String.toString(), which returns itself!
 
Maulin Vasavada
Ranch Hand
Posts: 1873
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Jeff

I know what that method is supposed to do but the name is not appropriate. If you are using IDE and intellisense pops up this method to you and if you are not aware of what exactly it does you end up having incorrect implementation. Don't you? (Well, atleast I did that).

Thanks
Maulin
 
Jeff Bosch
Ranch Hand
Posts: 808
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I totally agree. That's why I put the String.toString method. Some methods seem silly, some just confusing, and it gets really bad when a confusing method has confusing documentation. Heck, for some I even scratch my head after reading the API!

For Boolean.getBoolean, a better name might be Boolean.getPropertyValueIfThePropertyExistsAndIfTheValueIsTrue, but they had trouble fitting that into the API title bar.
[ October 25, 2004: Message edited by: Jeff Bosch ]
 
Ranch Hand
Posts: 1923
Scala Postgres Database Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The first idea would be to have a method in String:
,
because we have already a String as source, and don't need a Boolean (Wrapper) at all - why it is static.

But for every class, we can examine from a String, the String class would need to be extended to one more method:



(Think of the hundret import-statements at top of String).

For our classes, it would be bad, because, not owning the String class, we couldn't extend it.

So I think it was a wise decision, to write the method to the class, which needs the service.
would have been a more readable name, and would fit to all Classes, I guess.
 
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
[B][Stefan]:

would have been a more readable name, and would fit to all Classes, I guess.[/B]

Have you looked at the other wrapper classes, like Integer? They all have parseXXX() methods - but those methods always return the corresponding primitive value, not a wrapper object. There are also valueOfXXX() methods which return wrapper objects rather than primitives. So if we wanted a method in Boolean that returned a Boolean from parsing a String, the logical name for such a method (based on well-established patterns) would be Boolean.valueOf(String). Which, coincidentally, is in fact a method in the Boolean class. Convenient, no?

As for getBoolean(), I agree it's an embarrassingly bad name for the method. I'm guessing someone named it that way back somewhere in JDK 1.0, and now Sun doesn't want to break backward compatibility for the few poor souls who are using the method. :roll: I would suggest that the method should have been in the System class, next to getProperty(). A good name would have been getBooleanProperty() or maybe getPropertyAsBoolean(). Oh well.

Jeff: String's toString() method is actually useful. What should happen if toString() is called on a String? The default implementation of toString() in Object would return something like

java.lang.String@7d772e

Is that a good representation of a String? Since it is, in fact, a String, why not return itself? That's why toString() is defined in String - to override Object's default implementation.

You may be wondering why anyone would ever call toString() if they already have a String. But remember, you may be in a context where you don't yet know what kind of object you have, but you want to print its value anyway. Remember that you may implicitly call toString() on an object just by putting a + next to it (provided there's another String on the other side) - so it's easy to call toString() on an object without realizing it. String's toString() is just there to provide slightly more sensible behavior in case that happens.
 
Stefan Wagner
Ranch Hand
Posts: 1923
Scala Postgres Database Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ah, yes.
I needed a moment to get the difference.
Integer.parseInt (s);
Double.parseDouble (s);
but
Boolean.getBoolean (s);

But parseInt and parseDouble isn't the best name in my eyes too, since what is parsed is a String.

was even more confusing to me in my beginnings, because from the name, I would it expect to return the value of an Object - the primitive typ, while parseDouble might mean both - double or Double.
The capital 'D' is no help, due to the naming conventions, which demand an uppercase letter.
Only 'parseInt' instead of 'parseInteger' makes clear, that we don't get an Integer here.

Fortunately, I very rarely need 'getBoolean' or 'valueOf', and I'm used to Integer.parseInt (s); which I need more often.

public static boolean Boolean.parseBoolean (s)

could be introduced now, and marking getBoolean deprecated, to remove it in JDK 8.0 ([((perhaps))])

getProperty[asBoolean] doesn't get my vote.
It's too long and doesn't fit to the rest.

And why place it in the System class?
Put every ...parse... in the System class?
 
Jim Yingst
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
[SW]: But parseInt and parseDouble isn't the best name in my eyes too, since what is parsed is a String.


Well, to me "parse" aready implies that we're looking at a String (or some other stringlike thing, such as a Reader or a CharSequence) in order to interpret it as something else. I suppose that the simplest method names would've been Integer.parse(String) and Double.parse(String), since the return types are already implied by the class name. Except that an int is not the same as an Integer, etc.

[SW]: public static boolean Boolean.parseBoolean (s)

could be introduced now


Errr... have you looked at the API lately?

[SW]: getProperty[asBoolean] doesn't get my vote.
It's too long and doesn't fit to the rest.

And why place it in the System class?
Put every ...parse... in the System class?


More confusion here. When I suggested System.getBooleanProperty() and System.getPropertyAsBoolean(), I was talking about a replacement for the very poorly-named Boolean.getBoolean(). Not for the parseBoolean() or valueOf() methods. The getBoolean() method is very, very different from the other two methods, because it looks for a system property and interprets it as a boolean. None of the other methods in Boolean have anything at all to do with system properties. On the other hand, the System class has a getProperty() method, which is obviously similar. Boolean.getBoolean() is actually a mix of System.getProperty() and Boolean.parseBoolean() - it could be part of either Boolean or System, I suppose. But since they gave it such an incredibly poor name, it just causes confusion in Boolean, and to me it seems more similar to System.getProperty() than Boolean.parseBoolean().
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Jeff Bosch:
More useful than String.toString(), which returns itself!



That's actually quite usefull, because it can be used polymorphically. Just take a look at the source of String.valueOf(Object) - it couldn't be implemented that easily if String.toString wasn't implemented the way it is.

Boolean.getBoolean, on the other hand, might be usefull, but is certainly named inappropriately. Actually everyone I know who has used it, has used it accidentally and wrongly at the first try.
 
Stefan Wagner
Ranch Hand
Posts: 1923
Scala Postgres Database Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
[sw]: public static boolean Boolean.parseBoolean
could be introduced now
[jy]: Errr... have you looked at the API lately?
[sw]:And why place it in the System class?
Put every ...parse... in the System class?
[jy]:
More confusion here. (...)

Perhaps I got it now - used the offline 1.4.0 docs ...
[ October 28, 2004: Message edited by: Stefan Wagner ]
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic