Re: Allowing object field name shorthand

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

Re: are there metrics on how es6 and future proposals affect javascript load-time for webpages?

For what it's worth, if you're only interested in v8, have a look at the "Performance" panel in DevTools. You can inspect "Parse" and "Compile" time by in the Bottom-Up view, given that you've enabled `Timeline: V8 Runtime Call Stats on Timeline` in the hidden options of`Experiments`. On

Re: are there metrics on how es6 and future proposals affect javascript load-time for webpages?

> > First of all, ECMAScript requires an environment, which may or may not be > > a browser. So it might not necessarily make sense to assume "web pages" or > > browsers in the first place. > > wrong. all proposals eventually end up creeping into “web pages” or > browsers, either by adventurous

Re: are there metrics on how es6 and future proposals affect javascript load-time for webpages?

> First of all, ECMAScript requires an environment, which may or may not be a > browser. So it might not necessarily make sense to assume "web pages" or > browsers in the first place. wrong. all proposals eventually end up creeping into “web pages” or browsers, either by adventurous coders or

Re: Allowing object field name shorthand

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

Re: Allowing object field name shorthand

On Thu, Jun 22, 2017 at 7:56 AM, Sebastian Malton 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 > }; > >

Re: Allowing object field name shorthand

-1 this is a terrible idea in terms of debugging and code-maintennance. when debugging someone else's unfamiliar code, i now have to add an extra-check for quotes around the key. On Jun 23, 2017 1:36 AM, "T.J. Crowder" wrote: > If you know it's already valid

Re: Math.sincos(x)?

Also the sign of the `cos` component is wrong for a bunch of inputs. On Thursday, June 22, 2017 8:16:21 PM CEST Boris Zbarsky wrote: > On 6/22/17 2:13 PM, Алексей wrote: > > function sincos (a) { > > > > const sin = Math.sin(a) > > const cos = (1 - sin**2)**0.5 > > This will completely

Re: Math.sincos(x)?

On 6/22/17 2:13 PM, Алексей wrote: function sincos (a) { const sin = Math.sin(a) const cos = (1 - sin**2)**0.5 This will completely fail for a near pi/2. It will return zero instead of the correct small but nonzero value it should be returning. -Boris

Re: Math.sincos(x)?

On 6/22/17 2:02 PM, Robert Poor wrote: However, most implementations for cos(theta) actually generate sin(theta) as a "byproduct" (and vice-versa). At first glance, the v8 implementation of cos typically uses a Taylor series and does not compute sin. And the SpiderMonkey implementation of

Re: Math.sincos(x)?

If you think that performance of cos is too big (did you measure it?) than just calculate cos from sin with the formula sin^2 + con^2 = 1 ```js function sincos (a) { const sin = Math.sin(a) const cos = (1 - sin**2)**0.5 return {sin, cos} } ``` 2017-06-22 21:02 GMT+03:00 Robert Poor

Math.sincos(x)?

[Preamble: this is my first post to es-discuss -- if this isn't the right place to suggest language extensions, please let me know. Thanks. - rdp] How often have you seen code that calls Math.sin() and Math.cos() with the same argument, e.g: x = r * Math.cos(theta); y = r *

Re: Allowing object field name shorthand

If you know it's already valid syntax, then why suggest it mean something else? Breaking changes require **extremely compelling** justification (and new language modes, à la strict mode, which I don't think there's any appetite for at present). I'm still not seeing any solid benefits to repeating

Re: Allowing object field name shorthand

Okay, I know that "a.b" is already valid syntax but with the common field retrieval method this is inconsistent. ```jsconst obj = { "a.b" : 1 };const oak = { a : { b : 1 } };obj["a.b"] // This is the only way of getting this field oak.a.b oak["a"]["b"] // This object has as least two different

Re: Allowing object field name shorthand

On Thu, Jun 22, 2017 at 5:53 PM, Sebastian Malton wrote: > I would say that the easiest benefit would be the shorthand. > But as I pointed out, it's not shorthand unless the object only has one property. As of the second property, it's only more concise if the main

Re: Allowing object field name shorthand

On Thu, Jun 22, 2017 at 10:23 PM, Sebastian Malton wrote: > In my opinion the notation of {"n.b": 1} should equate to {n.b: 1} so that > object field retrieval is consistent. That's a hugely breaking change. ___ es-discuss

Re: Allowing object field name shorthand

Sure,I would say that the easiest benefit would be the shorthand. I have shown it to people and it apparently help with mongo integration. 1. I don't think that hidden behaviours is necessarily bad. It is not like this is an inconsistent from reassignment and adding a new level to the object 2.

Re: Allowing object field name shorthand

Can you expand on the benefits vs. costs (e.g., complexity, clarity)? I ask because I'm not immediately seeing a lot of benefit, but I'm seeing various costs: 1. It adds more hidden behavior (creating the object). 2. It makes object initializers more confusing to human readers. The syntaxes

Allowing object field name shorthand

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};would become var obj = {    field1: "val" ,    field2: {        field3: 3,        field4: true    }};and

Re: Deterministic Proposal

On Thu, Jun 22, 2017 at 9:14 AM, Andreas Rossberg wrote: > On 22 June 2017 at 01:24, Guy Ellis wrote: > >> My thoughts are along the lines that the developer would decide what a >> deterministic function was and decorate/tag it as such. That's why I

Re: Deterministic Proposal

On 22 June 2017 at 01:24, Guy Ellis wrote: > My thoughts are along the lines that the developer would decide what a > deterministic function was and decorate/tag it as such. That's why I used > the word deterministic and not pure. Basically the developer is signaling > the