Allowing object field name shorthand
T.J. Crowder
tj.crowder at farsightsoftware.com
Tue Jun 27 14:36:14 UTC 2017
(Sorry, just seeing this as it went to my spam folder - Ron, Google claims
it "failed microsoft.com extra verification" or something like that.)
> In this example, the actual name for the property is the rightmost
> identifier of the expression. This differs from the proposal at
> the start of this thread, but may also be worth considering.
Very different, and much more useful and interesting. It builds on the
shorthand notation from ES2015 that does that for variables:
```js
const answer = 42;
const o = {answer};
console.log(o.answer); // 42
```
...by allowing for it with object properties as well:
```js
const o1 = {answer: 42};
const o2 = {o1.answer};
console.log(o2.answer); // 42
```
I **really** like that idea. Would be good to see a proposal for a champion
to consider.
It would need to take both kinds of property accessors into account, and
address the runtime semantics of the expression evaluating the property
name. E.g.:
```js
const names = {
get name() {
console.log("Getting name 'answer'");
return "answer";
}
};
const o1 = {answer: 42};
const o2 = {o1[names.name]};
console.log(o2.answer); //42
```
Presumably the above would output:
```
Getting name 'answer'
42
```
e.g., the `name` accessor is only run once. (Accessor side-effects only for
the purposes of example, natch.)
-- T.J. Crowder
On Sun, Jun 25, 2017 at 8:00 PM, Ron Buckton <Ron.Buckton at microsoft.com>
wrote:
> There is one place where I could see this syntax being useful, though with
> different semantics, is a feature from C# that I seen used to good effect:
> Dotted names for shorthand property assignments.
>
>
>
> For example:
>
>
>
> ```
>
> const results = books.map(x => ({
>
> x.isbn,
>
> x.title,
>
> x.category.categoryName
>
> }));
>
>
>
> // creates: [{ isbn: 123456789, title: “…”, categoryName: “…” }, …]
>
> ```
>
>
>
> In this example, the actual name for the property is the rightmost
> identifier of the expression. This differs from the proposal at the start
> of this thread, but may also be worth considering.
>
>
>
> Ron
>
>
>
> (My apologies for formatting as I wrote this up on my phone)
>
>
>
> *From: *Mark <mark at heyimmark.com>
> *Sent: *Sunday, June 25, 2017 10:09 AM
> *To: *Michael Kriegel <michael.kriegel at actifsource.com>;
> es-discuss at mozilla.org
> *Subject: *Re: Allowing object field name shorthand
>
>
>
> Another -1 for this.
>
> It adds complexity to object initializer processing, both in the obvious
> way (has to figure out to create the hidden object or possibly several
> nested hidden objects), and around the fact that object initializers are
> processed in source code order.
>
> Exactly, this proposal assumes nested objects and that the nested key is
> referencing that object. But to assume this is problematic. What if the
> user wants the nested value to be something other than a plain object? with
> this approach, they’re stuck with just creating native objects.
>
> Not that it isn’t a good idea, but I think the negative effects of this
> change outweigh the benefit.
>
>
>
> On Fri, Jun 23, 2017 at 1:27 AM Michael Kriegel <
> michael.kriegel at actifsource.com> wrote:
>
>> I also vote against this. A further problem could be duplication of field
>> names in large objects. Imagine there is a field2.field3.field4.field5 in
>> the beginning of your object and then another one 100 lines below. Using
>> the currently well defined way to define nested objects at least groups
>> fields which belong to an object.
>> var obj = {
>> field1: "val" ,
>> field2.field3: 3,
>> //hundrets of lines
>> field2.field3: true
>> };
>>
>> Also it is much shorter, not to repeat the field names each time:
>>
>>
>> var obj = {
>> field1: "val" ,
>> field2:{
>> field3: 3,
>> field4: true
>> }
>> };
>>
>> Michael
>>
>> On 23.06.2017 04:13, Sebastian Malton wrote:
>>
>> I don't see how this is like referencing the object a field is in during
>> object construction. Yes field2.field4 would not be able to reference
>> field2.field3 but that is not what I am proposing. I am proposing a
>> syntactic sugar for nested objects
>>
>> On 2017-06-22 10:05 PM, J Decker wrote:
>>
>>
>>
>> On Thu, Jun 22, 2017 at 7:56 AM, Sebastian Malton <sebastian at malton.name>
>> wrote:
>>
>>> I would like to propose that the dot or '.' is allowed in object field
>>> names so that the following are allowed.
>>>
>>> var obj = {
>>> field1: "val" ,
>>> field2.field3: 3,
>>> field2.field4: true
>>> };
>>>
>>>
>> This is much like
>> var obj = {
>> field1: 3
>> field2 : 4
>> field3 : obj.field2+3
>> }
>>
>> which falls apart because obj isn't technically fully defined, and
>> doesn't have a field2. So your second field2.field4 wouldn't be able to
>> reference the previous object created for field2.field3.
>>
>> it would be a huge complexity for engines to create objects....
>>
>>
>>>
>>>
>>> Sebastian
>>>
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.mozilla.org%2Flistinfo%2Fes-discuss&data=02%7C01%7Cron.buckton%40microsoft.com%7C7b17930c80684f1f39fc08d4bbecef60%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636340073695179420&sdata=lM%2F%2FqR59EHpS5NiVvfbbAxv2KwaLmgwpCjvIdocekw4%3D&reserved=0>
>>>
>>>
>>
>>
>> _______________________________________________
>> es-discuss mailing listes-discuss at mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.mozilla.org%2Flistinfo%2Fes-discuss&data=02%7C01%7Cron.buckton%40microsoft.com%7C7b17930c80684f1f39fc08d4bbecef60%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636340073695179420&sdata=lM%2F%2FqR59EHpS5NiVvfbbAxv2KwaLmgwpCjvIdocekw4%3D&reserved=0>
>>
>>
>>
>>
>> _______________________________________________
>> es-discuss mailing listes-discuss at mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.mozilla.org%2Flistinfo%2Fes-discuss&data=02%7C01%7Cron.buckton%40microsoft.com%7C7b17930c80684f1f39fc08d4bbecef60%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636340073695179420&sdata=lM%2F%2FqR59EHpS5NiVvfbbAxv2KwaLmgwpCjvIdocekw4%3D&reserved=0>
>>
>>
>> --
>> Michael Kriegel • Head of R&D • Actifsource AG • Haldenstrasse 1 • CH-6340 Baar • www.actifsource.com <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.actifsource.com&data=02%7C01%7Cron.buckton%40microsoft.com%7C7b17930c80684f1f39fc08d4bbecef60%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636340073695179420&sdata=cwg13cOw7lzLmFuPCwwrXxJUbDciFlCSYwclwgvVHhI%3D&reserved=0> • +41 56 250 40 02 <+41%2056%20250%2040%2002>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.mozilla.org%2Flistinfo%2Fes-discuss&data=02%7C01%7Cron.buckton%40microsoft.com%7C7b17930c80684f1f39fc08d4bbecef60%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636340073695179420&sdata=lM%2F%2FqR59EHpS5NiVvfbbAxv2KwaLmgwpCjvIdocekw4%3D&reserved=0>
>>
>
> _______________________________________________
> 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/20170627/8f912d32/attachment-0001.html>
More information about the es-discuss
mailing list