Automatic interpolation of variables into string literals is a bad idea IMHO.
Couple that with variable hoisting (function scope) and hilarity can ensue when variables defined further down a function influence the value of another variable that looks like it just contains a string literal.
It's not really automatic interpolation. You have to very explicitly place the variable name inside ${var}. I'm puzzled in how you would think this will happen accidentally, or more accidentally than writing "+var+".
I've used Ruby quite a while and never experienced any problems with the very same construct in there.
You can also get away with doing just "$var", though, which is the problem. We encountered a strange bug the other day where having a string containing "$3" meant it never appeared on the page after (with it being converted to null).
Somehow you have to get those values into the String, though. How do you propose doing it? Seems to me you can either concatenate Strings ("hello "+name) or interpolate ("hello #{name}")? Interpolating actually looks cleaner to me.
Or of course create_string("hello $1", name) or something like that.
Definitely. It can't be used for i18n though, which is problematic (interpolation usually uses full expressions, so it's essentially a vector of code injection).
> Or of course create_string("hello $1", name) or something like that.
There are already string formatting minilanguages, no need to make up your own: you can use printf's format or C#-style string formats (I think the C# one is rather nice, especially its extensions in Python which allow for implicit positional and named formatting)
Strings with interpolation look different in ES6. They don't just look like string literals. You can easily see where the variable substitutions happen.
Also, I don't know what your argument about PHP is all about. I don't agree with the idea that string interpolation is going to lead to people writing code vulnerable to SQL injection, for example. You can just as easily write "select * from foo where name=\"" + name + "\"" as `select * from foo where name="${name}"`.
No you can't. You've got 8% more character and 2 switches between string context and expression context. It does not "flow" it's something which is forced on the user by limitations of the language.
Every time I try Ruby, this features seems odd, yet I never see much discussion of it. It feels unnatural to me, coming from a python background, and the only real advantage I can see is the fact that you do not have to type `.format(foo")` after the string, or some similar construct.
What advantages did I miss? I doubt that the creators of ruby did not put any thought into this, and I'd be interested in their justification.
> why is that better than string interpolation (which has also been around for decades)?
For my money, you can't use string interpolation for i18n alongside a semi-arbitrary access site (e.g. Transifex or Launchpad's Rosetta) and it's riskier for logging (for performance-related reasons, as it forces an eager interpolation where the logging API can provide for lazy formatting)
these are good reasons for having a string templating system in a library, but I was referring to the 90% use case of having a script that outputs something it computes.
Sure but now you have two very different ways to format your strings and language users need to realize they should be using the one they're not used to for these specific tasks, even though there's pretty much nothing helping make them realize it.
That significantly increases the user's cognitive load, and the risks of misusing APIs unless your language is able to express (and safegard against) the danger of string interpolation in specific contexts.
>> I doubt that the creators of ruby did not put any thought into this, and I'd be interested in their justification.
I don't know what Matz's thinking was, but it may just be that Ruby owes a great deal to Perl. Interpolation in double-quoted strings is present in Perl (and used constantly).
I think the bad part of string interpolation is that it encourages to use it constantly, in place, instead of extracting it to method.
Gluing strings together is the weak point of application, and should be hard to do, to encourage people to wrap it in functions, that can also validate input, escape what needs to be escaped, etc.
Maybe that's my "discipline and bodage" part talking :)
I'm a very small-scale, amateur programmer, but that sounds like over-engineering to me. Getting variable values into strings is often necessary. A programming language shouldn't make something common hard, just to enforce a particular view of best practices. Note: I'm not saying that "make it a method" is a bad idea - in general or in the case of a specific project or a specific size of codebase. But I don't like the idea of the language enforcing such a restriction.
Having said that, my first language was Perl, and I'm still a fan of TMTOWTDI and making common things easy.
Does anyone know what the rationale was for choosing this instead of printf or python3-style interpolation (where you explicitly specify the variables to be interpolated)?
