3 ms·
Note, that Java had to maintain backward compatibility, so they couldn't inject any new syntax into existing string literals. So, they had a choice between: 1.
by sesm 3y ago
Note, that Java had to maintain backward compatibility, so they couldn't inject any new syntax into existing string literals. So, they had a choice between:
1. Introducing syntax for new kind of string literals (like JS did)
2. Make some kind of explicit function/constructor call (like they ended up doing).
Advantage of 2 is that it doesn't require any new support from IDEs/parsers/code quality tools/etc. It is slightly more verbose, but not as verbose as some other Java syntax. IMO they've made the right decision.
- ghusbands 3y agoBut the solution does need support from IDEs and parsers. STR."\{STR."\{a}"}" is a valid expression, now, that uses a variable, and looks nothing like any previously valid expression. Given that it is an entirely new kind of expression, it's also unclear why they would choose \{ over { or need the dot. Is there some reason that they couldn't have chosen STR"{a}"?
- masklinn 3y agoExcept they did both: `\{` is not currently valid, so the "explicit function / constructor call" is completely unnecessary. Furthermore, they went on to use a printf-style formatting spec prefixing the template leader. > Advantage of 2 is that it doesn't require any new support from IDEs/parsers/code quality tools/etc. Of course it does, the sequence "IDENTIFIER, PERIOD, STRING LITERAL" is currently invalid, anything beyond a tokeniser should choke on it.