

Destructuring Assignment in ECMAScript 6 - mnemonik
http://fitzgeraldnick.com/weblog/50/

======
kevincennis
For anyone interested in trying some of this stuff out (which I highly
recommend, because a lot of the new stuff in ES6 is really great), Google has
an awesome tool called Traceur [[https://github.com/google/traceur-
compiler](https://github.com/google/traceur-compiler)] that will compile ES6
into ES5.

There's also an online version here: [[https://github.com/google/traceur-
compiler](https://github.com/google/traceur-compiler)] that's great for quick
little experiments. And, as an added bonus, it encodes your script in the URL
so you can share it.

~~~
thurn
Sounds like the Modules implementation isn't ready yet, that's too bad...
probably one of the most useful parts of ES6

~~~
kevincennis
Yeah. There are some other things that are actually impossible, like WeakMaps.
But still, the stuff that exists is pretty awesome.

------
mrspeaker
This, and the short function syntax (that's also already in Firefox stable:
"let square = x => x * x") make me very giddy. It's always been possible to
write JavaScript in a functional style - but this kind of sugar makes it much
much nicer. Things like Traceur will even let us transpile to old-school JS
for old browser support, so for a lot of projects we can start using these
things real soon.

~~~
mnemonik
Combine the two:

    
    
        const tail = [, ...xs] => xs;

~~~
Benvie
const tail = ([, ...xs]) => xs;

~~~
mnemonik
Ah you can't do the single-param-drop-parens when combined with destructuring?
Good to know, thanks Benvie.

------
santialbo
For anyone wondering, TypeScript will also include support for this
[http://typescript.codeplex.com/workitem/15](http://typescript.codeplex.com/workitem/15)

------
STRML
This is great and allows us to do some slicker functional code:

    
    
        function take(num, list) {
          if (num <= 0 || !list || list === []) return [];
          var [head, ...tail] = list;
          return [head].concat(take(num - 1, tail));
        }
    

It's not as elegant as haskell but it's still nicer than it would be without
the new syntax.

Once we have support for tail call optimization, things will get really
interesting.

~~~
vjeux
Note: list === [] doesn't do what you expect it to do. It's going to return
false all the time because it is comparing the actual objects and not their
content.

~~~
STRML
Ah, yeah, of course. That always threw me off, I've been working too much in
other languages.

------
scribu
Yet another great feature heavily inspired from CoffeeScript (and tastefully
expanded upon). Well done!

The surprising thing for me is that destructuring _almost_ allows defining
default values for function arguments.

~~~
pjscott
Destructuring assignment long predates Coffeescript. According to the
Coffeescript docs, they took the syntax from earlier drafts of ES6.
Destructuring assignment long predates ES6. Common Lisp had a destructuring-
bind macro back in the early 90s, and I'd bet it wasn't a novel invention back
then.

~~~
masklinn
And even in JS-land itself, Mozilla introduced destructuring assignment in
Javascript 1.7 (alongside iterators, generators, array comprehensions and
`let`).

Javascript 1.7 was introduced in Firefox _2_ , in October 2006.

> I'd bet it wasn't a novel invention back then.

Indeed, ML featured destructuring assignment (which it called "patterns") of
tuples and records back in the 70s.

------
xhrpost
Definitely looking forward to this as well as other new ES6 stuff. There's
something else I feel I could use perhaps even more but I haven't seen it in
any of the ES* updates. I'm a huge advocate of DRY and it bothers me when I
have to code something like:

    
    
      var a = objImUsing.prop.someLongName > 5 ? objImUsing.prop.someLongName : whatever;
    

I can and sometimes just make an extra variable above for a long prop list
like this but that adds an extra line. I guess what I would like would be some
sort of implied line limited scope:

    
    
      var a = objImUsing.prop.someLongName > 5 ? _1 : whatever;
    

_1 referring to the first mentioned value in the immediate parent statement.

~~~
ptgloden
In ES6, you can write more terse immediately invoked function expressions. So
you could use

    
    
      var a = (prop => prop > 5 ? prop : whatever)(objImUsing.prop.someLongName)
    

rather than

    
    
      var a = (function (prop) { return prop > 5 ? prop : whatever })(objImUsing.prop.someLongName)

------
agentultra
I can see why Brendan Eich is excited to get ES6 out there. It's finally
coming back around to parity with Scheme. I'm looking forward to seeing more.

~~~
AlexanderDhoore
Javascript is the functional programming community's secret weapon! Sure ES6
will add classes, but they're just syntactic sugar. Wrappers around the truly
functional language underneath. Everyone is slowly being soothed into using a
lisp. And when you realise this, it's the funniest thing to watch!

~~~
agentultra
I'd be hard-pressed to call Javascript a "functional programming language"
(whatever _that_ means). Common Lisp also suffers from the same misguided
label. In truth we love to mutate state in CL and find lattices of type
hierarchies to be burdensome (but a great pool of research for your post-doc).

Scheme is about as close as I'll get to pure-FP languages. I don't seem ES6
going down the "purity," route. And I hope it stays far from the border.

What I was originally referring to though is (if I recall the history of the
language) the roots of Javascript -- that it purportedly was a Scheme-like
language before becoming what it is today. And by being what it is now has
lagged behind in feature-parity to what programmers are used to in other
languages whose history isn't tied to the venerable web browser. It just seems
to me from the interviews that skirt the topic that Mr. Eich is finally coming
back around to introduce what should have been there from the start.

 _(Updated for clarity)_

~~~
MatthewPhillips
You could use const all over the place.

~~~
AlexanderDhoore
Still doesn't give you immutable data structures though. For example:

    
    
        const myArray = [42];
        myArray.push("Oh noes");
    
        [42, "Oh noes"]

~~~
MatthewPhillips
Ugh, you're kidding?

EDIT: checked in Node, yep. That's unfortunate. Can we get a let foo immutable
= [1]; or something?

EDIT2: Although this can be implemented in user-land with Object.freeze.
Create a function that returns a const that is frozen if it is non-primitive.
That should cover it, right?

~~~
kevingadd
freeze/seal don't actually provide true immutability in JS. There are cases
where a frozen object can still be modified (Date is one of them, IIRC typed
arrays are another)

------
Spoom
PHP has this available as list[1] in a slightly more limited form.

1\. [http://php.net/list](http://php.net/list)

~~~
andyroid
That was my first thought too. I never really cared for list() in PHP as I
find it a somewhat confusing way of assigning variables, and judging by the
examples given in the article, I actually preferred the clarity of the less
"terse" variable assignments done the old way. Might just be habit though.

~~~
Spoom
Yeah, I never really got it either. Seemed "clever", and I usually try to
avoid being too "clever" with code. Readability almost always wins.

------
cldr
Good to see, this is one thing I have really missed from Erlang when writing
Javascript.

~~~
mnemonik
This isn't quite as powerful as full blown pattern matching (which in turn
isn't quite as powerful as full blown unification) because you can't branch
logic based on whether a pattern matches or not.

~~~
kibwen
Can you elaborate on what "unification" is in this context? The only language
that I've used with full-blown pattern matching is Rust, and I'm curious to
know what the next step up the ladder is.

~~~
dragonwriter
A fairly decent, brief answer is here:

[http://stackoverflow.com/questions/4442314/differences-
betwe...](http://stackoverflow.com/questions/4442314/differences-between-
pattern-matching-and-unification)

------
crazygringo
That's awesome.

Any bets on when we can start using it on the front-end? I'm sure Chrome/FF
will pick it up quick once it's finalized, but when will ECMAScript 6 be
present in 95% of IE installations? 2020?

~~~
pjmlp
You are forgetting all the mobile browsers out there.

------
NKCSS
With the Destructuring Objects, I was like: WTF, but it all makes sense once
you get to the Practical Applications of Destructuring. Nice stuff.

~~~
masklinn
FWIW "objects" destructuring is just about as old as "tuple" destructuring: ML
had both in the 70s, which it called "tuple patterns" and "record patterns".

------
marshray
Who needs ML when now we have Javascript?

I never thought I'd hear myself say that. But seriously, this is awesome.
Thank you, whomever!

------
kclay
This is nice, reminds me of Scala

