Extensible destructuring proposal

[Ben Newman]

I too am fond of Scala's extensible pattern matching. Before I knew about
Scala's approach, I thoughtlessly agreed with the conventional wisdom that
pattern matching and object-oriented programming are necessarily at odds.
Letting objects define their own destructuring semantics shows that wisdom
to be mistaken, and your Symbol.extractor method feels like a perfectly
ECMAScript-y way to implement it.

That said, virtually every time I've written an unapply or unapplySeq
method in Scala, it has been with multi-case pattern matching in mind, and
we're only talking about destructuring assignment here, which I suppose is
like a single-case pattern match.

If you have time/motivation to put together a proposal for
Symbol.extractor, I would very much encourage you to think about the
possibility of introducing multi-case pattern matching as well, as I think
that would add significant value to the proposal, as well as highlighting
some tricky issues.

I'd be happy to review and/or help champion such a proposal, if it works
out as nicely as I hope!

Ben

On Tue, Jul 21, 2015 at 10:23 AM Bergi <a.d.bergi at web.de> wrote:

> Samuel Hapák schrieb:
>
> > The main idea is, that if object defines `Symbol.get` method, it gets
> used to access properties of object instead of `[]` when destructuring.
>
> Aw, when I read "extensible destructuring" I had hoped to see an
> extension to the destructuring syntax, not to see how semantics of
> destructuring objects are changed.
>
> What do you think about extractor functions, like in Scala
> <http://www.scala-lang.org/old/node/112>?
> Instead of `unapply` or `unapplySeq` methods we'd probably use an
> `@@extractor` (`Symbol.extractor`) method or so, allowing us to do
>
>      let Map({a, b, c}) = myMap;
>
>      let List(a, b, c) = myList;
>
>      const Map({author: Map({name: {first, last}, birthdate})}) = book;
>
> which would desugar to
>
>      let [{a, b, c}] = Map[Symbol.extractor](myMap);
>
>      let [a, b, c] = List[Symbol.extractor](myList);
>
>      const [{author: __author}] = Map[Symbol.extractor](book);
>      const [{name: {first, last}, birthdate}] =
> Map[Symbol.extractor](__author);
>
> where each extractor method would return an Iterable that is assigned to
> the "arguments" of the extractor. (A Proxy to lazily destructure object
> literals in there is a good idea, thanks @Claude).
>
> This would even allow us to call functions on destructuring, think about
> module imports:
>
>      // a.js
>      export default function factory(options) {
>          …
>          return moduleInstance;
>      }
>
>      // b.js
>      const NoOptions = {
>          [Symbol.extractor](factory) { return [factory()]; }
>      };
>      const WithOptions = (...args) => ({
>          [Symbol.extractor](factory) { return [factory(...args)]; }
>      });
>
>      import NoOptions(A) from "a";
>      import WithOptions("config")(A) from "a";
>      // A === moduleInstance
>
> What do you think about that?
>
>   Bergi
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150721/17dfc727/attachment.html>