Just a bit of musing here . . . what do you think the reason was / is, for the designers of Java to have chosen the 'set' of method names "valueOf()" in the String class? "Value" - to me - normally carries a numeric significance, yet String.valueOf(17) returns a String, not a number. Would it not have been more appropriate to have named this set of methods something like "stringOf()" instead?
Could be . . . (btw, I can see only 24 classes that contain valueOf() as a method) . . . and to take one of them, Byte for example, it returns a Byte, so in that sense at least, it's understandable. To me. ;) Following the logic of String's valueOf(), it should return another String - but of course to obtain that, you'd have to call toString() on it.
;)
CEHJ
Check out the Javadoc index for valueOf. I counted that number of classes
krakatoa
ASKER
Lol - I did, and I only found 2 dozen. But I don't doubt you are right.
What do you think of Byte.valueOf(byte) returning a Byte?
Well, for the reasons I've outlined. Of course I am not saying these methods do not work or are otherwise deficient . . . but there seems to be an enormous amount of super-overloading going on, which, for me is confusing . . . sometimes you get a String, sometimes another type. That makes it more difficult, not less, to remember which way the function is really pointing.
Sorry - i thought the point about it returning its own type went without saying
krakatoa
ASKER
Not sure then that *I* made my point well enough to begin with . . . although I thought I had via this :
"... String.valueOf(17) returns a String, not a number. Would it not have been more appropriate to have named this set of methods something like "stringOf()" instead?"
I was only talking about the superficiality of the method name - not what it does as such.
;)