How about `obj{p1, p2}` (without the dot)? `obj{p1}.p1 === obj.p1` for
example seems more elegant to me than `obj.{p1}.p1 === obj.p1`. I'm not
sure if that syntax would be ambiguous though.

On Wed, Sep 21, 2016 at 1:39 PM, Bob Myers <r...@gol.com> wrote:

> > Some people on a web site are curious to know if they can reduce 2
> lines of JS code to 1 line
>
> Right, some people wanted to reduce 2 lines of JS code
>
> ```
> const a = o.a;
> const b = o.b;
> ```
>
> to 1 line
>
> ```
> const {a, b} = o;
> ```
>
> and that's how we ended up with destructuring assignment, which managed to
> make its way into the spec. Actually it's not just one less line; it's more
> semantic and readable and less bug-prone.
>
> I'm not giving excessive weight to the questions of a few folks on
> StackOverflow, but it is curious how frequent and obvious the questions of
> these real people writing real code are: "If I can deconstruct into
> variables, why can't I deconstruct into objects?"
>
> It's worth pointing out that on a scale of 0 to 100 of syntactical
> "newness", this proposal ranks quite low. We're not introducing new
> operators, for example. We're adding the option to specify existing
> deconstructing syntax after the existing dot syntax to obtain an object
> with those deconstructed properties.
>
> Another answer to this thread suggested that picking properties into a new
> object could be handled by userland code. Sure it could, and already is, in
> the form of Underscore's `_.pick` etc. Yes, this is syntactic sugar. So is
> deconstructing assignment.
>
> But it's a tiny bit more than mere syntactic sugar. Writing `obj.{p1, p2}`
> is just sugar for writing `{p1: obj.p1, p2: obj.p2}`. But I can also write
> `obj.{p1: q1, p2 = 100}` to take advantage of the familiar ability of
> deconstructing syntax to rename and specify defaults, not to mention
> picking deeply, or using computed property names. That is something that
> would be very hard to implement in a userland function--ok, maybe not
> difficult, but cumbersome--do you really want to specify deep picks as
> `"a.b.c"`?. And it would be a real challenge to write a TypeScript
> signature for any version of `_.pick`, much less one that handled renaming,
> defaults, and deep picking.
>
> I totally agree with Matthew Robb's comment in a separate response that
> this proposal is not imposing a new cognitive burden; it's REMOVING the
> cognitive burden of wondering why our handy deconstructing syntax cannot be
> used to pick properties into objects.
>
> --
> Bob
>
>
>
>
>
>
> On Wed, Sep 21, 2016 at 8:10 PM, Jason Orendorff <
> jason.orendo...@gmail.com> wrote:
>
>> On Tue, Sep 20, 2016 at 2:38 PM, Bob Myers <r...@gol.com> wrote:
>>
>>> People in the real world continue to wonder why they can't
>>> pick/destructure from objects into objects, instead of just variables.
>>>
>>> http://stackoverflow.com/questions/39602360/es6-destructurin
>>> g-reassignment-of-object?noredirect=1#39602360
>>>
>>> This is actually the second such question on SO in the last week.
>>>
>>
>> Well, this not as weighty a consideration as you might think.
>>
>> Some people on a web site are curious to know if they can reduce 2 lines
>> of JS code to 1 line. Their shared curiosity may be a coincidence; or it
>> may be the language's fault. Presume the latter. It doesn't follow that the
>> answer should be yes. Since all new syntax imposes some mental load on all
>> language users, the answer should be no unless the benefit is really
>> dramatic, which I don't think it is here.
>>
>> -j
>>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
- Oli

Olivier Lalonde
http://www.syskall.com <-- connect with me!
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to