On Wed, Sep 21, 2016 at 12:33 PM, Matthew Robb <matthewwr...@gmail.com>
wrote:

>
> On Wed, Sep 21, 2016 at 10:40 AM, Jason Orendorff <
> jason.orendo...@gmail.com> wrote:
>
>> 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.
>
>
> For the most part I can completely agree with the sentiment that all new
> syntax imposes some mental load on all language users but my question is
> how this applies when syntax RESTRICTIONS that seem counter-intuitive
> impose their OWN mental load.
>

Neither proposal can reasonably be seen as merely lifting unnecessary
restrictions. Emphasizing some words doesn't make this seem like less of a
stretch, to me.

I think the inspiration of this thread and the few before it comes from the
> fact that destructuring syntax and object literal shorthand syntax seem to
> share in a root syntax yet the two features are incompatible which makes
> the mental load of the restrictions more obvious.
>

If it were a matter of lifting restrictions, this would be a very different
conversation. I get that to you, that's all it is. But I have trouble
seeing how that is true in any objective sense. In the spec, this will look
like a bunch of new text and syntactic productions. And nobody is going to
look at `{{x, y} = obj}` and recover the meaning from previously learned
principles of the language. It's an extra thing to learn.

And of course it comes with its own "restrictions", as you put it; i.e. it
cannot do everything either. Now people will wonder if they can put some of
an object's properties in one new object and dump all the rest in another.
Or if there's a shorthand for

    let obj = complicated_expression();
    let result = {start: {{x, y}=obj}, size: {{w, h}=obj}};

that eliminates the temporary `obj`. And on and on forever.

-j
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to