Closed GoogleCodeExporter closed 9 years ago
This seems really, really weird to add a method with essentially the same API
but strictly weaker capabilities than a JDK method.
Original comment by wasserman.louis
on 29 Apr 2013 at 4:38
Was Preconditions.format needed for something specifically
Preconditions-related, or was there something that String.format wasn't giving
that Preconditions needed at that moment? Would anything else (in guava) be
able to benefit from that extra bit of functionality?
And overall, it really doesn't have to be public at Strings, if it only makes
sense for it to be public at Preconditions (if it makes sense at all to be
public).
I wouldn't ask anyone to implement Strings.format with all of the function of
String.format + Preconditions.format; if that is what it takes to have it
public at Strings, then I'd rather not put anyone through the trouble. It only
seemed convenient to have during the discussion in the alluded issue.
Original comment by jamie.sp...@gmail.com
on 29 Apr 2013 at 4:52
The one and only advantage of Preconditions.format over Strings.format is GWT
compatibility.
Original comment by wasserman.louis
on 29 Apr 2013 at 4:59
There's one more thing (good for Preconditions and bad in most other places):
https://code.google.com/p/guava-libraries/issues/detail?id=1382#c7
Original comment by Maaarti...@gmail.com
on 29 Apr 2013 at 7:57
What about performance? I remember `String.format` to be quite slow.
Original comment by j...@nwsnet.de
on 15 May 2013 at 2:44
This issue has been migrated to GitHub.
It can be found at https://github.com/google/guava/issues/<issue id>
Original comment by cgdecker@google.com
on 1 Nov 2014 at 4:12
Original comment by cgdecker@google.com
on 1 Nov 2014 at 4:18
Original comment by cgdecker@google.com
on 3 Nov 2014 at 9:08
Original issue reported on code.google.com by
jamie.sp...@gmail.com
on 29 Apr 2013 at 4:20