> > Remi and I have in the past had differences of opinion on the utility of > introducing CharSequence versions of such methods. > > One benefit to using a string is that the object is immutable; there are > no time-of-check-versus-time-of-**use conditions to worry about. Robust > code should arguably work sensibly even with mutable CharSequences, and the > easiest way to ensure that is to call the toString method of a CharSequence > passed as a parameter. > > -Joe >
It isn't typical to require that arguments to a method be immutable, and it is generally implicit that any arguments to a method that are mutated during the method's execution result in undefined output (to perhaps varying degrees). In an imperative object oriented language, attempting to eliminate any possibility of argument mutability is surely a doomed endeavour. I think in this case it is reasonable to leave it to the user to ensure that the input remains consistent for the duration of the call. It can be documented if necessary, but as I say I think all imperative methods come with that caveat by definition. Calling the toString() method as a solution is really no better than asking the user to do the same, albeit a little neater; the only reason a CharSequence method would be preferred is that you can avoid unnecessary object allocation. For a very lightweight method like parseInt, this can dramatically reduce the impact of making the call.
