
My ECMAScript 7 wishlist - radmuzom
http://www.nczonline.net/blog/2014/06/03/my-ecmascript-7-wishlist/
======
spankalee
Shameless 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.

~~~
gress
Dart is a Google proprietary product.

~~~
dragonwriter
Its 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
Not 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.

~~~
nknighthb
Pretty 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
C, C++, JavaScript, Java, Fortran

Only the vast majority of all commercial code ever written.

~~~
nknighthb
You've just proven my point while cleverly but unsuccessfully trying to avoid
being responsive to my inquiry. Java was never adopted in any form by a
standards body, three of the remaining four are an already-small and ever-
shrinking share of the industry, and ECMAScript is never up to date with the
latest developments in JavaScript.

~~~
gress
Even if you are right, and I'd only grant you that I am partially wrong about
java because the JCP has collapsed since the Oracle takeover - the rest are
just you adding qualifiers to minimize the contradiction, so what?

Your position is simply to dismiss the value of standards and state that it's
fine that Dart is proprietary.

Also your statement about ECMAScript is flat out disingenuous. JavaScript
implementations may move ahead between ECMAScript standards, but it _is_
standardized, and by a real cross-industry group, not just a rubber stamp from
one company.

It is hard to take seriously an assertion that the level of standardization
between Dart and JavaScript is comparable.

~~~
nknighthb
Nobody made that assertion. _You_ made an assertion that standardization is "a
pretty significant factor". You've yet to clarify what it's a significant
factor in, nor have you provided evidence that it is, in fact, significant.

I also didn't state that it's fine that Dart is proprietary, and I'd
appreciate you not putting words in my mouth. My position is that your premise
is incorrect and Dart is _not_ proprietary.

------
coldtea
The 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_
I 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
I 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
That 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
Yeah, 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
Putting 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.

------
Sonata
Can'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
It appears the author has already answered my question:

[http://www.nczonline.net/blog/2014/04/22/creating-
defensive-...](http://www.nczonline.net/blog/2014/04/22/creating-defensive-
objects-with-es6-proxies/)

------
tomp
Interesting 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
JS 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.

------
zimbatm
On 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_
They 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
If 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.

------
nijiko
Better 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

------
thathonkey
The 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
Extending 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
I 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
Nothing prevents you from using a function (`last(myArray)`). In a dynamically
typed language what you are proposing makes only very limited sense.

~~~
lomnakkus
I'm not saying functions are bad or anything. They just "feel" wrong since
they don't look like the built-ins.

Regarding "dynamically typed": CLOS[1] got this right. Common Lisp is
dynamically typed. In short: Dynamic/static typing has very little to do with
this.

[1]
[http://en.wikipedia.org/wiki/Common_Lisp_Object_System](http://en.wikipedia.org/wiki/Common_Lisp_Object_System)

------
Touche
These are all pretty minor things that can already be done in ES5.... The
biggest thing I want in ES7 is immutables.

------
bringking
Thanks 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
if (array && !array.length) { /* do something here */ }

Check existence as well, this also works for a jQuery selection.

