Would there be any possibility for the addition of native Long numbers to JavaScript, or is this, due to some nature of the language, something that can't, or shouldn't, be included?
64-bit bitwise operations would be a big help.
The Future of JavaScript
31–40 of 115 posts
Re: The Future of JavaScript
#32"Now "let" is the new "var" – traditional "var" declarations are complemented with "let" and "const". Both are properly block-scoped bindings, eliminating a common source of errors and weird behaviour." Somehow going from one keyword for variable declaration to three doesn't seem like a good way to reduce errors.
The extra keywords aren't going to reduce the "errors and weird behavior", the fact that they will be block-scoped and not function-scoped is what will eliminate the confusion.
I agree with geuis above, JavaScript scope is simple to understand now. There is global scope, and there is function scope. That's it. And there's a certain elegance to that.
Re: The Future of JavaScript
#33Earlier quoted context omitted.
I've only delved into really writing JS for the last couple of weeks, but a number of tutorials basically said that objects are dictionaries and vice versa, you just got some nice syntax and you can plug function in as values. If that was an abuse, what are JavaScript objects supposed to be? What's the difference between them and a dictionary?
It's only an abuse because JavaScript has no distinction between the notion of an object's "meta" properties, and its dictionary-like keys and values. So you'll get along just fine, until someone tries to write this: var dict = {}; dict["hasOwnProperty"] = true; dict["toString"] = "Bob"; dict["valueOf"] = 7; ... then you're in for a rough time.
Should be able to use Type.prototype.method (e.g., Object.prototype.hasOwnProperty).
Re: The Future of JavaScript
#34I'm probably alone in saying this, but I hope most of this stuff never sees the light of day. What makes JS powerful is its simplicity. "var" or no "var" gets you local or global scope. Done. Want a constant? Make a global variable and don't change it. Want to really make sure its unchangeable? Make an accessor function. Scope in JS is very simple to understand and quite versatile once understood. Adding more layers…
In my experience, the charm of simplicity of JS starts fading away when you start moving away from DOM manipulation and start writing complex objects. Just last week I ran into the lexical scoping issue ( I was not aware of it before) that had me scratching my head for hours. Scoping in JS becomes less fun the deeper you start digging. I am glad that they are aware of it and are actively trying to address it.
Re: The Future of JavaScript
#35"Now "let" is the new "var" – traditional "var" declarations are complemented with "let" and "const". Both are properly block-scoped bindings, eliminating a common source of errors and weird behaviour." Somehow going from one keyword for variable declaration to three doesn't seem like a good way to reduce errors.
The extra keywords aren't going to reduce the "errors and weird behavior", the fact that they will be block-scoped and not function-scoped is what will eliminate the confusion.
It doesn't though.
Because how are you ggoing to know that they operate that way? You will have to learn that somehow. And you couldve just as easily learned how var works instead.
What's worse.... now you still need to learn how var works anyway! It isn't gone. I see 0 reduction in confusion and +3 increase in cognitive load.
Re: The Future of JavaScript
#36As long as this doesn't become another difference between browsers (= headache).
Even with optimistic estimates, it's going to be years, likely decades, before you can rely on these features being supported by the majorly of browsers. That's kind of sad but is the hard reality. I hope they come up with a good design.
I think they should be very conservative about what they propose. It should be a very obvious improvement to the language or have a lot of design time spent on it. If all major browser developers are not on board (Microsoft?) then the improvement is much less valuable.
Re: The Future of JavaScript
#37Futures like in node-fibers? https://github.com/laverdet/node-fibers I think it is the proper way to complement generators and give the alternative to wait for a function value.
Re: The Future of JavaScript
#38> (Caveat: Iteration over collections is not yet specified) Is this a joke? Is not iterating over dictionaries and arrays javascript's most glaring weakness? How hard would it be to agree on something like foreach, that, you know, actually works the way you think it should work.
There is a foreach that works: .forEach(). And when you're not just iterating over an array but transforming it, you have map(), reduce() and filter().
Re: The Future of JavaScript
#39Is it really not out for 2 years? Really? That seems like a long time for not that much changes. Any improvement is welcome, but still. I don't know if this will keep pace with Dart and other options. It seems way too slow.
Really?
You seriously think Dart is anywhere close to taking over Javascript?
Re: The Future of JavaScript
#40Earlier quoted context omitted.
Byt anyone with even a basic tutorial understanding of the language wouldn't do that. Is it really necessary to try and make it absolutely impossible to get unexpected results? The downside is even more complexity and uncertainty. Now you have to know the old way, the new way, and the idiosynchracies of both.
You might not write: dict["valueOf"] since that's obviously a bad idea, but you might write: dict[user_provided_string] Since user_provided_string could be anything, you are susceptible to unexpected behavior if the string ends up being "valueOf".
But even if you use an arbitrary object....if it comes from a user supplied value you are going to have to validate it somehow.
It would be great if the post included good examples of how these things are going to produce better code. Maybe my imagination or experience is just insufficient to see the great win here.