71–80 of 94 posts
Using the ` (backquote) character for multiline strings isn't a wise choice (probably inherited from Go) cause it's difficult to reach that character on non-english keyboard layout. In the italian layout it's alt+\ or alt+9 on the Mac but you can't reach it using Windows; you need to press alt+96.
But, how are we going to migrate? Compile down to the current version and serve two files? I feel like this migration process will take way too long.
For some web apps it will probably take long. But with all the developments in browser land there is often more then one reason to develop against the latest anyway. Hopefully this will motivate corporate IT to move faster also.
By forcing my users to use the latest versions of Firefox and Chrome I get access to a lot of nice new functionality.
Using the ` (backquote) character for multiline strings isn't a wise choice (probably inherited from Go) cause it's difficult to reach that character on non-english keyboard layout. In the italian layout it's alt+\ or alt+9 on the Mac but you can't reach it using Windows; you need to press alt+96.
Using the ` (backquote) character for multiline strings isn't a wise choice (probably inherited from Go) cause it's difficult to reach that character on non-english keyboard layout. In the italian layout it's alt+\ or alt+9 on the Mac but you can't reach it using Windows; you need to press alt+96.
What other character would you suggest? At least multi line strings arent super common (nor essential) so extra difficulty isn't a major problem.
var a = "abc
def";
var a = "a very "
"very long string";Earlier quoted context omitted.
That's the idea. Python uses the same syntax for multi-line strings as for comments.
> Python uses the same syntax for multi-line strings as for comments. 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 * doc strings . As the name indicate, they're strings , they're not comments and should no…
Earlier quoted context omitted.
I don't know much about PHP, what's wrong with it regarding templating?
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.
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}"`.
I think it will be really sad if we end up with a module system that's incompatible with CommonJS, which is the only such system that has gained any real traction.
`let` is good but please, give me `let ... in` too: let callback = function(a, b) { // ... } in object.registerCallback(callback);
I don't know what they've selected for ECMAScript 6, but the `let` keyword as introduced in Firefox 2 has 3 different forms: * Let definitions are equivalent to `var` but block-scoped, so if (x > y) { let gamma = 12.7 + y; i = gamma * x; } `gamma` is local to the `if` block and will not leak out. This form can be used to create bindings in `for` as well: for ( let i=0 ; i * Let statement, mostly for side-effects, suf…
Sadly it's not. JS has some semantic foibles, but I find myself up against syntax more often than I'd like. Every time I write it I'm impressed at how ugly the syntax is vs for such a good language (modulo the standard library.)
The very thing I'm trying to avoid is the use of blocks within parentheses. (Aside: I changed my font to Monaco for JS because of the frequent appearance of `})`, and went to the trouble of fixing it up in Fontforge so gvim et al. would be willing to use it.)
I never want to see this:
anything(block {
// ...
}) 64-bit integers and bitwise operations together with default arguments and destructuring would solve just about everything.