RFR: CSR JDK-8203630 Add instance method equivalents for String::format
John Rose
john.r.rose at oracle.com
Wed May 23 22:10:49 UTC 2018
On May 23, 2018, at 2:07 PM, Remi Forax <forax at univ-mlv.fr> wrote:
>
> Please, don't call it format too !
> Trying to do a :: on a class with instance methods and static methods with the same doesn't work well, and format() being a varargs will not help.
>
> I see several reasons to not introduce this method whatever its name (interpolate ?),
> - String.format is very slow (compared to the String concatenation), providing several new slow methods doesn't seem to go to the right direction
> - the problem can be solved easily by writing a the javadoc sentence saying that one can use a static import, or write an article about String.format(), or better talk with Eclipse/Jetbrains, so they will add a quickfix to do the static import automatically like with assert* in tests.
> - at some point in the future, we may want to add a way to interpolate strings in Java, the runtime support, StringConcatFactory, is already in the JDK.
Refactoring static as non-static methods, or vice versa, is a very
reasonable design move, but the language makes it hard to do this
and retain backward compatibility. It's a pity, and we could do something
to make this easy. The basic idea, which I've been plumping for a long
time but hasn't got much love, is to simply allow static methods to be
called using instance method syntax, given appropriate opt-in. Then
format would be opted-in and all would be well.
class String {
public static __Fluent String format(String thsi, Object… args) { … }
}
See also: https://bugs.openjdk.java.net/browse/JDK-8191530
This addresses interface statics, which serve as a stand-in for
non-interface final methods (because you can't override them).
The fact that they *also* require a special invocation syntax
(prefix instead of postfix/fluent) is just an accident of notation,
which should be adjustable by an API designer.
Legacy prefix and new postfix syntaxes would co-exist by
virtue of overload resolution rules, with legacy getting priority
much as with varargs and autoboxing. We'd have to deprecate
and outlaw existing legacy semantics (for classes not interfaces)
of fluent notation for statics which *discards* the LHS of the dot
after evaluating it. That's the trickiest bit, but the details are IMO
manageable.
I can dream.
— John
More information about the core-libs-dev
mailing list