> Can anybody name the pitfalls or point to where they have been mentioned
(if any have been)?
The pitfalls have been mentioned in various responses on related threads
over the last year or two.
I will take a stab at summarizing them, with my response/comments to each.
Apologies in advance if I mischaracterized anyone's views or put words in
their mouth..
*1. The problem (picking properties into an object) is not common enough,
or important enough, to worry about.*
Maybe. Maybe not. For whatever reason, it's quite common in my own
development (which is why I started thinking about this and continue
flogging it). It may or may not be relevant that the problem has been asked
on SO dozens of time, as well as frequently appearing on this mailing list.
I don't doubt that some people may not need to do this very often, but is
there any chance they're projecting their particular field or style of JS
onto the rest of the world?
*2. Even if picking is a common use case, it can be done without the new
syntax.*
Yes, that is the definition of "syntactic sugar". But merely being
syntactic sugar is in and of itself not a sufficient reason for rejecting a
proposal. Many proposals have been accepted over the years which are only
or mainly syntax sugar. It boils down to a trade-off between how sweet the
sugar is and how intense the cravings, which ends up being quite subjective.
*3. Even if you agree that new syntax is useful, the improvement in
convenience does not justify the added language complexity. *
There are two sides to the equation here: the improvement in convenience,
and the added language complexity. We need to consider both to assess this
tradeoff. Whether one considers the improvement in convenience large or
small, in this case the added language complexity can fairly be
characterized as low in my opinion.
*4. There are just too many dots and curly brackets in this syntax, and/or
it's cryptic, or hard to read, or not obvious.*
In an earlier version of the proposal, one would write `{ {a, b} = p }`,
which does seem to have a few too many `{` right next to each other. The
current version is to say `p.{a, b}`. One might complain that it is easy to
overlook the dot, I suppose. In terms of being "obvious", to me it seems
quite obvious that if `a.b` means to take property `b` from `a`, then
`a.{b,c}` would mean to take `b` and `c`.
Here are some other potential pitfalls, which to my knowledge have NOT been
raised in connection with this proposal.
*5. The proposed new syntax forecloses possibly useful future extensions.
such as "eating" some valuable special character).*
Since the only syntax change is allowing a left curly bracket after a dot,
the proposed syntax "blocks" almost nothing in the future we can think of.
*6. The proposed new syntax tricky to parse.*
I'm not a parser guy, but the syntax changes are limited to detecting the
`{` after the dot, and what comes then is exactly the same deconstructing
construct that parsers already know how to parse.
*7. The proposed new syntax incompatible with existing syntactic
constructs.*
I can't see how this could possible be the case. To the contrary, it is
completely compatible with both dot notation (specifying properties to
access or set after a dot), and deconstructing syntax.
--
Bob
On Sun, Mar 18, 2018 at 9:39 AM, Naveen Chawla <[email protected]>
wrote:
> Yes it seems like a natural combination of the destructuring and object
> shorthand features (the `=` version that is). Can anybody name the pitfalls
> or point to where they have been mentioned (if any have been)?
>
>
> On Sun, 18 Mar 2018 at 08:52 Michael Theriot <
> [email protected]> wrote:
>
>> Not up to speed with any pitfalls already discussed but for what it's
>> worth I tried this at least a few times when destructuring landed and was
>> disappointed it didn't work.
>>
>> On Mar 16, 2018, at 4:30 PM, Sebastian Malton <[email protected]>
>> wrote:
>>
>> Hello currently the following is a possible way to define an object.
>>
>> ```
>> var d = { a, b, c };
>> ```
>>
>> But this only works if the fields are already variables.
>>
>> So if you wanted to select some fields from an object within you have to
>> use temp variables, reference the field by name but without the temporary
>> variables, or use some immediately called functions which is messy.
>>
>> So I propose the following syntax:
>>
>> ```
>> var d = {
>> a,
>> b,
>> { c }: e
>> };
>> ```
>>
>> Here d will have the fields [a, b, c] and the values are the variable a,
>> variable b, and value e.c.
>>
>> Other things like name reassignment would work too.
>>
>> Sebastian Malton
>>
>>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
