Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enhanced format(String format, Object... args) in Strings #1389

Closed
gissuebot opened this issue Oct 31, 2014 · 7 comments
Closed

Enhanced format(String format, Object... args) in Strings #1389

gissuebot opened this issue Oct 31, 2014 · 7 comments
Labels

Comments

@gissuebot
Copy link

Original issue created by jamie.spencer.86 on 2013-04-29 at 04:20 AM


This issue derives from #1382 .

Could Preconditions.format(String, Object...) become public as a member of the Strings helper class? That method doesn't seem particularly dependant on Preconditions and seems well suited for any set of (String, Object...) arguments.

I would hope that Strings.format only allowing %s flags, would not misleading any users, but documentation handles that well enough.

Other than that, I feel that it would be useful outside of Preconditions.

@gissuebot
Copy link
Author

Original comment posted by wasserman.louis on 2013-04-29 at 04:38 AM


This seems really, really weird to add a method with essentially the same API but strictly weaker capabilities than a JDK method.

@gissuebot
Copy link
Author

Original comment posted by jamie.spencer.86 on 2013-04-29 at 04:52 AM


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.

@gissuebot
Copy link
Author

Original comment posted by wasserman.louis on 2013-04-29 at 04:59 AM


The one and only advantage of Preconditions.format over Strings.format is GWT compatibility.

@gissuebot
Copy link
Author

Original comment posted by Maaartinus on 2013-04-29 at 07:57 PM


There's one more thing (good for Preconditions and bad in most other places):
#1382

@gissuebot
Copy link
Author

gissuebot commented Nov 1, 2014

Original comment posted by [email protected] on 2013-05-15 at 02:44 PM


What about performance? I remember String.format to be quite slow.

@JanecekPetr
Copy link

It seems there is a significant demand for this, see e.g. most currently http://stackoverflow.com/questions/29747912/, but also the older, but massively popular http://stackoverflow.com/questions/513600/ and http://stackoverflow.com/questions/12786902/.

The standard answer is to use String.format()/MessageFormat if you care about readability and flexibility, then to use a StringBuilder if you need performance.
In the 90% of cases, this is good enough.
In the rest, under the assumption we don't need the flexibility of String.format(), a simple concatenation/StringBuilder can be hideous.

As of now (2015/05) and to my best knowledge, the current best is slf4j MessageFormatter, but its API could definitely be improved.
If the Strings.format() method were published, it would immediatelly be the nicest and clearest option out there.

@dimo414
Copy link
Contributor

dimo414 commented May 15, 2018

Fixed by 7fe1702 😃

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants