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!
Give a man a fish, he'll eat for one day. <br />Teach a man to fish, he'll drink all your beer.<br /> <br />Cheers,<br /> <br />Jeff (SCJP 1.4, SCJD in progress, if you can call that progress...)
Maulin Vasavada
Ranch Hand
Joined: Nov 04, 2001
Posts: 1865
posted
0
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
Joined: Jul 30, 2003
Posts: 804
posted
0
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 ]
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.
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.
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
Sheriff
Joined: Jan 30, 2000
Posts: 18670
posted
0
[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().
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.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
[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 ]
0
