Luke Mitchell (2016-11-02T13:26:29.000Z)
Aside from performance, the operator also leads to denser code which is easier to write. Talking to my colleagues, I was told that two of them could have used it already this morning!

Luke Mitchell

Luke Mitchell

Software Developer

On Wed, 02 Nov 2016 at 13:12 Isiah Meadows

<
mailto:Isiah Meadows <isiahmeadows at gmail.com>
> wrote:

a, pre, code, a:link, body { word-wrap: break-word !important; }

That's not likely to make any serious performance difference with an ajax call. And in tight loops, I try avoid conditionals and object creation anyways, to avoid branch prediction fails (in both the engine and CPU) and costly allocation. (Most engines only do a limited form of pooling for faster GC.)

On Wed, Nov 2, 2016, 09:04 kdex <
mailto:kdex at kdex.de
> wrote:

I'd imagine that from an engine point of view, this means that fewer

object shapes land in memory, at least for v8.

Reducing the number of object shapes currently boils down to using an

object literal and setting the properties to `value || null` instead of

extending the object with new properties imperatively.

On Wednesday, November 2, 2016 12:38:05 PM CET Isiah Meadows wrote:

> What benefit would this bring over imperatively adding properties?

>

> On Wed, Nov 2, 2016, 08:18 Luke Mitchell <
mailto:luke at enki.com
> wrote:

>

> > Hi all,

> >

> > I often come across a situation where I wish to extend an object

> > (usually an argument for an API request) if a particular condition is

> > satisfied, such as the presence of a function parameter. Currently the

> > only way to do this is by assigning the object to a variable, checking

> > the condition using an `if` statement and then extending the object. I

> > am proposing the inclusion of an operator that allows a property to be

> > included, subject to a particular condition, inside the object

> > definition.

> >

> > The operator looks like this:

> >

> > ```

> > let obj = {

> >   cond ? prop: value

> > };

> >

> > ```

> >

> > The operator could also be used with a block statement, allowing

> > multiple properties to be included:

> >

> > ```

> > let obj = {

> >   cond ? {

> >     prop1: value1,

> >     prop2: value2

> >   }

> > };

> > ```

> >

> > I have created a draft proposal and would love to hear any thoughts

> > you have on the matter. You can find it on my GitHub, at the link

> > below.

> >

> >
https://github.com/lukem512/proposal-condition-property-definitions
> >

> > Kind regards,

> > Luke

> > _______________________________________________

> > es-discuss mailing list

> >
mailto:es-discuss at mozilla.org
> >
https://mail.mozilla.org/listinfo/es-discuss
> >

>

_______________________________________________

es-discuss mailing list
mailto:es-discuss at mozilla.org https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________

es-discuss mailing list
mailto: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/20161102/bec925c6/attachment-0001.html>
luke at enki.com (2016-11-02T13:29:14.711Z)
Aside from performance, the operator also leads to denser code which is easier to write. Talking to my colleagues, I was told that two of them could have used it already this morning!

Luke
luke at enki.com (2016-11-02T13:28:54.306Z)
Aside from performance, the operator also leads to denser code which is easier to write. Talking to my colleagues, I was told that two of them could have used it already this morning!

Luke Mitchell

On Wed, 02 Nov 2016 at 13:12 Isiah Meadows

<
mailto:Isiah Meadows <isiahmeadows at gmail.com>
> wrote:

a, pre, code, a:link, body { word-wrap: break-word !important; }

That's not likely to make any serious performance difference with an ajax call. And in tight loops, I try avoid conditionals and object creation anyways, to avoid branch prediction fails (in both the engine and CPU) and costly allocation. (Most engines only do a limited form of pooling for faster GC.)

On Wed, Nov 2, 2016, 09:04 kdex <
mailto:kdex at kdex.de
> wrote:

I'd imagine that from an engine point of view, this means that fewer

object shapes land in memory, at least for v8.

Reducing the number of object shapes currently boils down to using an

object literal and setting the properties to `value || null` instead of

extending the object with new properties imperatively.

On Wednesday, November 2, 2016 12:38:05 PM CET Isiah Meadows wrote:

> What benefit would this bring over imperatively adding properties?


> On Wed, Nov 2, 2016, 08:18 Luke Mitchell <

mailto:luke at enki.com
> wrote:


> > Hi all,

> >

> > I often come across a situation where I wish to extend an object

> > (usually an argument for an API request) if a particular condition is

> > satisfied, such as the presence of a function parameter. Currently the

> > only way to do this is by assigning the object to a variable, checking

> > the condition using an `if` statement and then extending the object. I

> > am proposing the inclusion of an operator that allows a property to be

> > included, subject to a particular condition, inside the object

> > definition.

> >

> > The operator looks like this:

> >

> > ```

> > let obj = {

> >   cond ? prop: value

> > };

> >

> > ```

> >

> > The operator could also be used with a block statement, allowing

> > multiple properties to be included:

> >

> > ```

> > let obj = {

> >   cond ? {

> >     prop1: value1,

> >     prop2: value2

> >   }

> > };

> > ```

> >

> > I have created a draft proposal and would love to hear any thoughts

> > you have on the matter. You can find it on my GitHub, at the link

> > below.

> >

> >

https://github.com/lukem512/proposal-condition-property-definitions
> >

> > Kind ,

> > Luke

> > _______________________________________________

> > es-discuss mailing list

> >

mailto:es-discuss at mozilla.org
> >

https://mail.mozilla.org/listinfo/es