Yeah I agree with that one completely: unless I tell you I don't care for it, you don't get to ignore it.
It's in line with JS's non-strict handling of arguments though (missing args are `undefined`, extra args are in the `arguments` object), which makes it hard to argue against)
> Templating: hello, PHP! I thought we already know better
Meh. Ruby also lets you do that, it's OK. String formatting is a good idea and interpolation is no worse than sprintf-style or C#-style.
Why should that fail any more than:
var a = foo[0];
var b = foo[1];
// rest of foo unused
That said, if they're going to include destructuring, it'd be nice if they also included a way to bind the tail.
Depending on the language, either you don't or you use a "everything else" operator to an unused variable:
a, b, *_ = list
a, b, * = list
a, *, c = list
And people often use _ as a placeholder when not using splatting:
a, _, _, c, d = list
I like Python solution there:
list = [1,2,3,4,5,6,7,8,9,10]
a,b,c = list[0:3]
a,b,c = list[0:4]
a, b, c, *_ = list
a, *_, b = listI don't get why strict restructuring is a bad thing... as long as it's consistant, it's just a nuance of the language.
Am I missing side effect of this? What are potential pit-falls of this pattern?
a,b,c=[1,2,3,4]
You could also do
a,b,c = list.slice(0,3);
var [ a, b, ...rest ] = fooCouple 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.
I've used Ruby quite a while and never experienced any problems with the very same construct in there.
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)
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.
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.
"hello $name we welcome you in hour team '$teamName' of ${members.size}"
"hello %s we welcome you in hour team '%s' of %d" % (name, teamName, members.size)
"hello {name} we welcome you in hour team '{teamName}' of {members_size}".format(name=name, teamName=teamName, members_size=len(members))
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)
The things don't seem mutually exclusive to me.
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 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).
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 :)
Having said that, my first language was Perl, and I'm still a fan of TMTOWTDI and making common things easy.
The main issue is that half of these features don't solve any real problem. They should look to libraries like underscore that add features and solve problems that JS currently doesn't. It's almost like they just want to eliminate libraries altogether and have everything work out of the box.
In one of C++ programs I've worked on, we've had 4 different classes for string used (along with char* of course).
With libraries, you are free to switch to other ones if you don't like the way it does a specific thing. Don't like CommonJS? Don't use browserify, and instead try RequireJS. Don't like how Prototype extends the prototype of objects? Try jQuery.
var foo = /* Hello there How are you? */;
But less typing is good too.
By the fact that you included spaces in your example, does that imply it doesn't include the surrounding spaces in the string? Maybe your example implies that spaces are not included, but maybe they are or maybe they aren't, since comments don't require them, but usually have them and look ugly without them.
I think it's a bad idea to use C-style comments as multi line strings, because it's ambiguous and/or ugly because of the surrounding spaces. If the leading and trailing spaces are included in the string, then it looks "/ * [nospace] ugly [nospace] * /", and it drops the surrounding spaces like your example implies, then "/ * [nospace] what does it mean [space] * /" if you omit one or both spaces? Messy and ambiguous.
It looks like something the C++ committee would come up with when they ran out of punctuation characters, and decided to abuse existing syntax instead. Comment overloading, an extension of Generalized Overloading for C++2000: http://www2.research.att.com/~bs/whitespace98.pdf
[I can't format an example of what I mean literally and had to add extra spaces, because of hn's stupid formatting rule: "Text surrounded by asterisks is italicized, if the character after the first asterisk isn't whitespace."]
/ * ... * / is a comment in Javascript. Changing it to mean multi-line string is a terrible idea.
This list of changes to Javascript borrows so much from Python I'm surprised they didn't also borrow Python's multi-line string syntax.
No it does not. Triple-quoted strings are still strings, all comments in Python are prefixed with `#`.
There are two situations where triple quoted strings are used as "comments":
* Multiline comments for lazy people, as Python has no multiline comment syntax
* docstrings. As the name indicate, they're strings, they're not comments and should not be confused by more ad-hoc systems such as javadoc comments. Python lets you write `help(name)` and get the docstring associated with the object
Default arguments: good. Clearly useful and already used a lot with the if (foo === undefined) foo = 'default' pattern.
Non-strict destructuring: bad. It's neither destructuring-bind nor pattern matching... If I destructure a 3-list to 2 vars, I want it to fail, dammit!
Multi-line strings: good, obviously.
Templating: hello, PHP! I thought we already know better.
List comprehension: useful.
My humble opinion: it's hopeless. A mix of useful and terrible features means it'll still be made out of "the good parts" and the awful rest.