On Wed, Sep 21, 2016 at 3: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 [...]
>
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
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
