RFR: CSR JDK-8203630 Add instance method equivalents for String::format (original) (raw)
John Rose john.r.rose at oracle.com
Wed May 23 22:10:49 UTC 2018
- Previous message: RFR: CSR JDK-8203630 Add instance method equivalents for String::format
- Next message: ServiceLoader.load(Class, ClassLoader) does not load services exposed in modules and loaded by parent CL
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: RFR: CSR JDK-8203630 Add instance method equivalents for String::format
- Next message: ServiceLoader.load(Class, ClassLoader) does not load services exposed in modules and loaded by parent CL
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]