Extended dot notation (pick notation) proposal

Bob Myers rtm at gol.com
Thu Sep 22 18:14:40 UTC 2016

With regard to deep picking, with standard destructuring I write

const {foo: {bar: { qux }}} = obj;

which means

const qux = obj.foo.bar.qux;

In the proposed "pick/destructure into an object" syntax, I would use
identical destructuring syntax

obj.{foo: {bar: {qux}}}

which would turn into `{qux: obj.foo.bar.qux}`.

We are simply using identical destructuring syntax to destructure into an
object instead of a variable.

Sorry for using ALL CAPS. I will not do that any more. You're right: this
proposal DOES (oops, I meant *does*) increase the size of the spec. Is that
the new criteria, that no proposal may increase the size of the spec? Then
we might as well freeze JS right now.

The "extra words" you refer to are nothing more this:

> You can also put deconstructing syntax following a dot after an object.
This will result in a new object with properties determined by the

None of the ES6 enhancements made "JavaScript: The Definitive Guide" a
shorter book. Are you saying that means they should not have been included
in the spec?


On Thu, Sep 22, 2016 at 9:56 PM, Jason Orendorff <jason.orendorff at gmail.com>

> On Wed, Sep 21, 2016 at 3:39 PM, Bob Myers <rtm at 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 [...]
> That is not historically how JS got destructuring.
>> 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}` [...]
> In destructuring, `{p1: q1} = obj` means `q1 = obj.p1`. So, do you mean
> for this to say `{q1: obj.p1}`? Or perhaps `{p1: obj.q1}`; but then why is
> it inconsistent with destructuring?
> You mention deep picking, but I haven't seen what that would actually look
> like. (Destructuring is not great for deep picking, so I'm not sure how the
> new syntax requires negative effort to learn because it's all existing
> parts, and yet it will also solve this problem.)
> You mention computed property names. How does that work? In `obj.{[p1]}`,
> does `p1` mean the variable `p1` or the property `obj.p1`? Assuming the
> former, is there anyplace else in the language where adding `[]` affects
> what an identifier refers to (i.e. scoping)?
> How is all of this not a ton of new things for JS developers to learn?
> 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.
> This argument is hopeless, and I find it a little weird because a much
> stronger argument is available to you. You can just say, yes, there is some
> minor complexity cost here, but it's definitely worth it because of very
> common use cases X, Y, and Z.
> The argument you've chosen instead won't go. None of these proposals could
> actually be standardized in a way that reduces the total size of the spec.
> They won't make "JavaScript: The Definitive Guide" a shorter book, either.
> They all require extra words to explain, whether to implementors or to JS
> devs. New syntax does not make things simpler, in the same way that up is
> not down and black is not white.
> Cognitive burden is a real phenomenon, where people have to spend time
> puzzling out unfamiliar ideas and it's pure overhead for them vs. their
> actual goal. You can't just turn the meaning of the term upside down and be
> done. It actually means something.
> (Also, both you and Matthew seem to think an unlikely point can be carried
> with the help of allcaps. Admittedly they are very judiciously applied
> allcaps, relative to the internet at large, but I still don't think this
> ever works!)
> -j
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160922/2e32b488/attachment-0002.html>

More information about the es-discuss mailing list