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 fi
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 Friday
> > 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 co
> 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 fr
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 T
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
> };
>
>
This is much like
var obj =
-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 syntax, then why suggest it mean some
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 f
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
___
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 co
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 :
[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 * Math.sin(theta);
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
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 wa
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
property name is just one char
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 mailing list
es-discuss@mozi
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. In
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 `{"a
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 even
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 used
>> the word deterministic and not pure. B
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 compiler that given an
21 matches
Mail list logo
