Allowing object field name shorthand

[Ron Buckton]

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<mailto:mark at heyimmark.com>
Sent: Sunday, June 25, 2017 10:09 AM
To: Michael Kriegel<mailto:michael.kriegel at actifsource.com>; es-discuss at mozilla.org<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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>



--
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<tel:+41%2056%20250%2040%2002>

_______________________________________________
es-discuss mailing list
es-discuss at mozilla.org<mailto: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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170625/05440022/attachment-0001.html>