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 <[email protected]> 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 > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
