6 ms·
My ECMAScript 7 wishlist
- spankalee 12y agoShameless plug, but the author should check out Dart. Dart's core libraries include first, last, isEmpty, isNotEmpty getters for Iterables, as well as a ton of functional methods like map(), where(), reduce(), expand() (flatMap). Not only do the built-in Lists implement Iterable, but so do NodeList, so you can do things like: var e = query('#id').children.first; Dart's annotations would serve as custom property descriptors, and mixins are like traits. Having interfaces in general is also hugely beneficial. It also sounds like he leans towards wanting closed classes with your requests for deepSeal and defensive classes. This does prevent a lot of errors. Both Dart and TypeScript give you this type of safety.
- radmuzom 12y agoGood points, but given the author is one of the most well known JavaScript engineers in existence today - I guess that it is highly likely that he has already checked them out.
- gress 12y agoDart is a Google proprietary product.
- dragonwriter 12y agoIts neither proprietary in the sense of closed implementation or in the sense of not having an open, freely implementable spec. Its "proprietary" only in the sense of "not adopted by a standards body".
- gress 12y agoNot adopted by a standards body is a pretty significant factor. It is also proprietary in that Google is in absolute control of the development process.
- spankalee 12y agoI think anyone can participate in the ECMA TC52 meetings. I'm not sure about membership in ECMA, I think there other requirements.
- gress 12y agoThere appears to be no activity or information about this process that is publicly available.
- spankalee 12y agoThat's a very legitimate complaint. Gilad Bracha sometimes posts updates[1] to the Dart mailing lists, but I'm not familiar with ECMA, or if it has a standard way of posting information and updates about technical committee work. I'll raise it with the team and see if we can have a place to post upcoming meetings, agendas, minutes, and decisions and draft specifications. It'd also be nice to have a way, besides the issue tracker (which like all issue trackers can seem like a black hole for issues for some people) to propose items for upcoming meetings. I find Python's PEP to be a pretty nice system. [1]: https://groups.google.com/a/dartlang.org/forum/#!searchin/misc/tc52%7Csort:date/misc/Oh_OSjx_Go0/AjntJpNp6w0J https://groups.google.com/a/dartlang.org/forum/#!searchin/mi...
- nknighthb 12y agoPretty significant factor in what? Write down all the reasonably popular programming languages you can think of. How many have been adopted by a standards body? How many have been adopted by a standards body in their current form? I hardly ever write code in a standardized language. Actually, I don't think I know anyone who writes code in a standardized language, because nontrivial programs in "standardized" languages almost always go outside the strict confines of whatever mediocre crap some committee adopted.
- gress 12y agoC, C++, JavaScript, Java, Fortran Only the vast majority of all commercial code ever written.
- spankalee 12y agoWell, we have ECMA TC52 which will hopefully ratify the specification pretty soon.
- cpeterso 12y agoBut proprietary in the sense of that there is only one implementation and it is maintained by one company (Google).
- _random_ 12y agoThat's not a big deal. Browsers are in a desperate need for a non-transpiled client-side language competition.
- gress 12y agoIt's the lack of competition that makes it a problem.
- spankalee 12y agoThere aren't that many languages that aren't "proprietary" in some way or another at their beginnings. C, Java, JavaScript, Rust, Go, Swift, Python, Perl, Ruby, Clojure, TypeScript... on and on. Haskell is one of the few modern languages I know of where a language was birthed in committee. ALGOL and COBOL are some older examples.
- Sonata 12y agoCan't the exception throwing on missing property behaviour be created using ES6 proxies? Anyway, while many of these things would be nice additions, I think ES7 will contain more low-level features which particularly benefit libraries and compile-to-js languages, such as SIMD support and value objects. Personally, I'd love to see tail call elimination in the spec.
- Sonata 12y agoIt appears the author has already answered my question: http://www.nczonline.net/blog/2014/04/22/creating-defensive-objects-with-es6-proxies/ http://www.nczonline.net/blog/2014/04/22/creating-defensive-...
- thathonkey 12y agoThe author complains about having to type "items[items.length - 1]" a bunch but then shows how to implement last() and first() himself very easily via prototyping 6 lines of code onto Array. So... what is the problem again? (a lot of the other stuff in the article is valid though)
- ben336 12y agoExtending a browser provided prototype shouldn't be done lightly. You certainly couldn't do something like that if you were writing a library, as you might conflict with somebody elses implementation of the same add on. There's also value in having things like this standardized. If its a common idiom, its worth including in the standard to allow people to use it without having to worry about what utility libraries they're including.
- lomnakkus 12y agoI actually tend to think that this kind of shows the folly of single-dispatch OO in general (prototypical or not), in particular its focus on privileging the first parameter syntactically. The problem here is essentially that a freestanding function looks and thus (subjectively) "feels" different from a method. The syntax is obviously slightly different: "myArray.last()" vs. "last(myArray)". The latter stands out as slightly "alien" when compared to the other methods on Array. Why should the first parameter be privileged? Why isn't it possible to add a new method to, say, Array which is scoped to your lexical context? Even classic procedural programming didn't have this problem (as long as you don't need access to private data): Just add a function that does what you want and it'll look and behave just as the other functions on Array. EDIT: Maybe the focus shouldn't be on adding a few convenience methods here and there, but rather on making the language itself more "pliable" or "growable" as Steele would probably say.
- jkrems 12y agoNothing prevents you from using a function (`last(myArray)`). In a dynamically typed language what you are proposing makes only very limited sense.
- coldtea 12y agoThe already said ES6 spec will be delayed again, this time for June 2015. So it will take until like 2020 to be able to use it without transpilers and hacks for all the non supporting browsers (most of them). So I don't have any ES7 wishes. Until then who knows even if I'll still be doing web front-end work.
- _random_ 12y agoI think it would be a safe bet to wish that ES7 has a better support of second generation quantum computation primitives and a good implementation of exocortex interoperability APIs.
- barosl 12y agoI think allowing the negative array index, like "items[-1]", would greatly improve the indexing problem. IIRC, JS strings also don't support negative indexes. Is this intended? I think the backward incompatibility that would be led by the change should be tolerable. And to my personal preferences, I prefer "items[0]" to "items.first()", though the latter is more "english". One of the comments from the post also suggests "items.slice(-1)[0]" as a replacement of "items.last()", but that's another case...
- TazeTSchnitzel 12y agoThat would break backwards-compatibility, however. Arrays are just objects with a magic .length property. As such, I can already do `items[-1] = 'foo';` and it'll create a property named "-1" and set it to "foo".
- barosl 12y agoYeah, that's what I wanted to say by the "tolerable" part. I know arrays, as well as other plain objects in JS, are capable of having arbitrary properties. But hey, how many libraries or code rely on that specific behavior of Array? For the "Greater Good", they can suppress those minor cases and simply extend the magic to the negative integer range. I believe this change can be landed without too much compatibility pain.
- kevingadd 12y agoPutting arbitrary properties on an Array, in practice, turns it into a hashtable or a 'mixed' hashtable+Array (this depends on the JS implementation. Dense array layouts are largely an optimization that the JS runtime applies if it's able to. So you 'can' put arbitrary properties on an Array, but you risk throwing away the benefits you get from using it instead of Object. Sadly the risk of compatibility pain is huge for almost every change you can possibly imagine. I've been participating on es-discuss for a couple years now and tiny, harmless changes end up breaking real web applications on a regular basis - causing the spec committee to have to scratch their heads and figure out a fix. Sometimes there isn't a fix, and they have to rethink.
- bringking 12y agoThanks for the article. I agree with most of this, however for empty arrays I find it best just to check length in the "falsy" way. Like - if ( !array.length ) { //do something } Seems succinct enough not to require a separate function.
- nijiko 12y agoif (array && !array.length) { /* do something here */ } Check existence as well, this also works for a jQuery selection.
- zimbatm 12y agoOn the other side of the spectrum, what improvements could be added to JavaScript the assembly language to make it easier and more efficient to target to ?
- _random_ 12y agoThey want everyone to think same way and use one single multi-purpose scripting language. JS as a bytecode is a less favourable outcome for them for some reason, maybe because everyone would stop caring about using JS directly. Hence the unfortunate lack of news on the asm.js side.
- kevingadd 12y agoIf by 'lack of news' you mean 'active development and more tools vendors introducing asm.js targets', sure. asm.js support keeps improving in all the major browsers, while Epic and Unity both have increasingly viable asm.js+WebGL backends. Furthermore, emscripten is moving towards being a mature LLVM backend instead of a separate compiler tool, and other compilers are adopting asm as well.
- Touche 12y agoThese are all pretty minor things that can already be done in ES5.... The biggest thing I want in ES7 is immutables.
- tomp 12y agoInteresting how this author uses WeakSet where a normal set would be completely equivalent; as long as the function is running, the toplevel object is reachable from the local variables, and so are all the "deep" objects, by definition (they belong to the toplevel object's reference graph). Therefore, there is no way that an object becomes unreachable after it has been visited by the algorithm (considering that JavaScript is single-threaded). The only reason I can see for this is if JavaScript has no normal sets.
- kevingadd 12y agoJS has Set and WeakSet, and Set is more powerful (it allows a wider variety of key types). It's actually quite rare for you to need a WeakSet.
- nijiko 12y agoBetter things to wish for: - async / promise / await - object merging / cloning (with options / deep) - array properties instead of methods (ruby style, array.first, array.last, array.empty, array.contains, etc...) - lets not forget other object types that need methods, Number, Boolean, String (.equals, .equalsIgnoreCase, etc...) Let's just say, javascript could be a lot better :P