Constructing objects from named identifiers

Bob Myers rtm at gol.com
Thu Jun 2 20:03:12 UTC 2016


OK, so from now on instead of `o.p` I will write

```js
(({p}) => p)(o)
```

Your second example misses the whole point. I do not want to deconstruct
into variables (and then laboriously reconstruct an object from those
variables). The entire notion is to deconstruct into objects.

I do not say this is "necessary", any more than `padStart` is necessary. I
say it's a convenient, compact way to extend dot notation to allow
extracting multiple properties into a new object. In your first example you
have repeated `a` and `b` not twice, but three times, and your entire code,
even if rewritten as `({a,b})=>({a, b})(o)`, is 20 characters, instead of
the seven in `o.{a,b}`, and **much** less readable. `{a: o.a, b: o.b}` is
sixteen, and also repeats `a` and `b` twice.

The meta question is what criteria we want to apply to proposed syntax
additions or extensions which boil down to syntactic sugar. We could say we
don't need no stinkin' sugar, and the only changes we will consider are
those that provide new functionality not implementable in user code. But
there is already plenty of precedent for sugar-level additions to the
language. So the criteria becomes to what extent does the sugar allow us to
write more semantic, compact, readable, and less bug-prone code. IMHO
`o.{a,b}` *does* qualify, opinions may differ.

Bob




On Fri, Jun 3, 2016 at 1:04 AM, Cyril Auburtin <cyril.auburtin at gmail.com>
wrote:

> I don't see a need at all for that, since anyway you often need other
> manipulations, so if you need a functional way you can do:
>
> `let foo = ({a,b})=>({a:a+1, b:b+2})`
>
> then use foo on o1
>
> or if you need to, you use destructuring declaratively:
>
> `let {a, b} = o1` or `({a,b} = o1)` when reassigning a and b
>
>
>
>
> 2016-06-02 21:06 GMT+02:00 Bob Myers <rtm at gol.com>:
>
>> The proposal of mine referenced by John in his link is obsolete, and has
>> been replaced by https://github.com/rtm/js-pick-notation, with a new
>> minimal variation at
>> https://github.com/rtm/js-pick-notation/blob/master/minimal/spec.md
>> which precisely leverages the current syntax and semantics of
>> deconstructing.
>>
>> John's proposal for picking into an anonymous object:
>>
>> ```js
>> ({p1, p2}) = o
>> ```
>>
>> overloads parentheses in a strange way, and is too easily confused with
>>
>> ```js
>> ({p1, p2} = o)
>> ```
>>
>> which means a completely different thing, and furthermore violates the
>> semantics of the assignment operator, which is that it evaluates to the
>> RHS, whereas he presumably intended this to evaluate to the newly created
>> object.
>>
>> The assignment operator `=` makes sense in current deconstructing
>> assignments, since it *is* an assignment. It makes no sense in the
>> context of picking properties into objects.
>>
>> In my proposal, this is
>>
>> ```js
>> o.{p1, p2}
>> ```
>>
>> which has a clear analogy to the "single property picking" syntax `o.p1`,
>> is syntactically unambiguous, easily parsable using existing machinery for
>> parsing deconstructors, and by virtue of re-using current deconstruction
>> syntax allows for renaming and defaults out of the box.
>>
>> I've approached a couple of possible champions for this but no dice so
>> far.
>>
>> --
>> Bob
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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/20160603/238aa6d6/attachment-0001.html>


More information about the es-discuss mailing list