I suspect OP misunderstood the destructuring syntax, otherwise it made zero
sense to me... FYI in the case of `({foo: bar}) => { ... }`, `bar` is the
alias of `someObject.foo`, not the other way around.And it's a bad idea because instead of an ad-hoc solution which is gonna waste another potential operator character slot I'd really like to see some general purpose pattern matching mechanism in place. On Fri, May 20, 2016 at 7:36 AM, Tab Atkins Jr. <[email protected]> wrote: > On Thu, May 19, 2016 at 8:59 AM, Michał Wadas <[email protected]> > wrote: > > Idea: > > > > function foo({bar, *: baz}) { > > > > } > > > > would be equivalent to: > > > > function foo(baz) { > > const bar = baz.bar; > > } > > > > Rationales: > > - little better IDE support (argument name reveals intention) > > - allows to write more concise code when handling case of getting common > > values and handling whole object optionally > > - improve pattern "use few properties of options object then pass it > deeper" > > - allows more expressive module import > > - allows to more concise code when destructuring expression result > > > > import {*: rand, generateRandomInt} from 'fancy-random-module'; > > import {*: moment, isMoment} from 'moment'; > > Other languages with destructing have a more explicit syntax for this > (giving a name to the container as well as its pieces), so that it > works in all the destructuring forms. In Haskell, for example, it > looks like "baz@{bar}". This is usable with list destructuring, too. > > ~TJ > _______________________________________________ > 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
