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.krie...@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 <sebast...@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@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
>
> _______________________________________________
> es-discuss mailing
> listes-discuss@mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss
>
>
>
>
> _______________________________________________
> es-discuss mailing
> listes-discuss@mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss
>
>
> --
> Michael Kriegel • Head of R&D • Actifsource AG • Haldenstrasse 1 • CH-6340
> Baar • www.actifsource.com • +41 56 250 40 02 <+41%2056%20250%2040%2002>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
