Suggestion: Destructuring object initializer.
Naveen Chawla
naveen.chwl at gmail.com
Sat Feb 10 04:30:59 UTC 2018
I'm not a TC39 member, but I have a little readability issue with
destructuring inside an object:
```js
{ {p1, p2} = p, {q1, q2} = q }
```
has a very different meaning than
```js
{ p: {p1, p2}, {q1, q2} = q }
```
On Fri, 9 Feb 2018 at 16:55 Bob Myers <rtm at gol.com> wrote:
> Thanks for your input.
>
> Actually, I was not trying to beat the dead horse of my property picking
> proposal, but rather give advice to another would-be spec proposer based on
> my experience.
>
> But since you brought it up, the spec for property picking can be found at
> https://github.com/rtm/js-pick-notation. As with any spec, one could
> argue that it's too brief, or too verbose, or missing this or that, but
> actually this is a very simple feature. There is a fair amount of
> discussion on this list about this proposal, in various iterations, over
> the last few years.
>
> As for an implementation, the TC39 process documents clearly state that
> the implementation types expected for Stage 0 (strawman) is "*N/A*". I'd
> be glad to write a Babel or sweet.js implementation, but I'm not quite sure
> what it would prove.
>
> Although the TC39 documents are murky on this point, and some of them
> appear to state that a proposal can gain Stage 0 status without a champion,
> other information seems to say that getting a proposal to Stage 0 DOES
> require the involvement of a TC39 member, even if they are not technically
> considered a "champion" at that point...As for "trying to find" such a
> champion, I thought posting to this group constituted such an effort, and
> in addition I have reached out to a couple of members with no response.
>
> Here's a real quick intro to the proposal:
>
> ```
> const {p1, p2} = p;
> const [q1, q2} = q;
> return {p1, p2, q2, q2};
>
> ==or==
>
> return {p1: p.p1, p2: p.p2, q1:q.q1, p2: q.q2};
> ```
>
> becomes
>
> ```
> return { {p1, p2} = p, {q1, q2} = q };
> ```
>
> Yes, it's pretty much sugar--no brand new functionality here. It's about
> brevity and expressiveness, which seems to have been a low enough bar for
> several other features to pass. It steals no new symbols. It clearly
> leverages existing destructuring assignment syntactical infrastructure.
>
> Bob
>
> On Fri, Feb 9, 2018 at 4:25 PM, Andy Earnshaw <andyearnshaw at gmail.com>
> wrote:
>
>> Bob, I think it's an interesting idea too, but you can't strong-arm
>> people into getting excited about what you're asking for. If it really is
>> that important to you then put together a solid proposal, write a Babel
>> plugin and then try to find a champion for it.
>>
>> On Thu, 8 Feb 2018 at 14:05 Bob Myers <rtm at gol.com> wrote:
>>
>>> It does make one stop and wonder why the group will endlessly entertain
>>> trolls debating whether or not ES6 (or ES5) portends the end of
>>> civilization as we know it, while relentlessly ignoring literally dozens of
>>> similar/identical proposals for property picking, a feature which easily
>>> contributes as much to the language at as little cost as many other
>>> features such as spread properties.
>>>
>> _______________________________________________
> 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/20180210/7d9a46cf/attachment.html>
More information about the es-discuss
mailing list