Just a note: there does exist a destructive method to do this:
`Array.prototype.reverse()`
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/reverse
-
Isiah Meadows
m...@isiahmeadows.com
www.isiahmeadows.com
On Wed, Jul 18, 2018 at 2:43 PM, Mike Samuel
On Wed, Jul 18, 2018 at 5:03 AM, J Decker wrote:
>
>
> Well; Since JSON (JavaScript Object Notation) there's now available to JS
> a feature that an 'n' suffix can be applied to a number. Seems JSON should
> just inherit that.
>
json.org states:
"It is based on a subset of the JavaScript
This won't work
>
> ``` desired object
> { a : 123, b : 123n }
> ```
>
> ``` json
> { "a":123 ,
> "b":123 }
> ```
>
> function test( json ) {
>var c = json.a * 5;
>var BIc = json.b * 5n;
> }
>
> if long numbers only translate to bigint (and small as Number); the calc for
> 'BIc'
On Wed, Jul 18, 2018 at 11:05 AM Michael Theriot <
michael.lee.ther...@gmail.com> wrote:
> I think `in` and `instanceof` could both benefit from having negated
> versions.
>
> Assuming the developer is using `in` correctly, hasOwnProperty concerns
> are irrelevant. Either way they would attempt
I think `in` and `instanceof` could both benefit from having negated
versions.
Assuming the developer is using `in` correctly, hasOwnProperty concerns are
irrelevant. Either way they would attempt to use !(a in b), not
!hasOwnProperty.
Same reason we don't use...
!(a == b) // a != b
!(a === b)
[sorry dropped group]
On Fri, Jul 13, 2018 at 11:36 AM wrote:
> This may be a silly idea that doesn't come naturally to others, but the
> first thing I thought of was "!n", where the "!" represents a flipped
> "i", so the inverse of in.
>
You'd need yet another restricted production which
On Wed, Jul 18, 2018 at 6:31 PM, Michael Luder-Rosefield <
rosyatran...@gmail.com> wrote:
> Is strikes me that every single Array method that takes an iteratee
function
> (signature (value, index, array)) should be able to iterate through the
> array in reverse, in a standardised way.
Yeah, I had
I partially agree with Michael Luder-Rosefield.
The main reason I started this thread is consistency. Because I can't get
the logic behind what Michael listed above.
I don't think I can support the idea of
`iterOrder`. Looks like a try to create silver bullet and I don't think
it's a handy way to
On Wed, Jul 18, 2018 at 5:31 PM, Michael Luder-Rosefield
wrote:
> At the moment, we have:
>
> every
> filter
> find
> findIndex
> forEach
> indexOf / lastIndexOf
> map
> reduce / reduceRight
> some
>
> which is not very consistent at all. Perhaps we could add an `iterOrder`
> method that changes
Sorry, I got lost.
I partially agree with Michael Luder-Rosefield.
The main reason I started this thread is consistency. Because I can't get
the logic behind what Michael listed above.
I don't think I can support the idea of
`iterOrder`. Looks like a try to create silver bullet and I don't think
On Wed, Jul 18, 2018 at 2:06 PM Nicolas B. Pierron <
nicolas.b.pier...@mozilla.com> wrote:
> On Wed, Jul 18, 2018 at 5:31 PM, Michael Luder-Rosefield
> wrote:
> > At the moment, we have:
> >
> > every
> > filter
> > find
> > findIndex
> > forEach
> > indexOf / lastIndexOf
> > map
> > reduce /
-- Forwarded message --
From: Dmitry Shulgin
Date: 2018-07-05 10:36 GMT+03:00
Subject: Feature proposal
To: es-discuss@mozilla.org
I came across a task of finding an index of the last element in array that
satisfies the condition, so i reversed array and found it by *findIndex *
On Tue, Jul 17, 2018 at 9:16 PM Isiah Meadows
wrote:
> The way this conversation is going, we might as well just create a
> schema-based JSON serialization DSL for both parsing and stringifying.
> But I don't really see that as helpful in the *language itself* at
> least as a mandatory part of
On Wed, Jul 18, 2018 at 12:21 PM Michael Theriot <
michael.lee.ther...@gmail.com> wrote:
> I think it is irrelevant; the operator already exists and I would assume
> if you want the negation of it you are using it correctly in the first
> place. Otherwise are you not just arguing for its removal
there you go
```
console.log([7, 4, 6, 7, 12].findIndex((_, i, a) =>
isPrime(a[a.length-1-i]))); // 3
```
Le mer. 18 juil. 2018 à 11:17, Dmitry Shulgin a
écrit :
>
> -- Forwarded message --
> From: Dmitry Shulgin
> Date: 2018-07-05 10:36 GMT+03:00
> Subject: Feature proposal
>
sorry you get 1, and need again to subtract the array length, `arr.length
-1 - 1` to get the final result 3
Le mer. 18 juil. 2018 à 18:41, Cyril Auburtin a
écrit :
> there you go
> ```
> console.log([7, 4, 6, 7, 12].findIndex((_, i, a) =>
> isPrime(a[a.length-1-i]))); // 3
> ```
>
> Le mer. 18
Is strikes me that every single Array method that takes an iteratee
function (signature (value, index, array)) should be able to iterate
through the array in reverse, in a standardised way.
At the moment, we have:
- every
- filter
- find
- findIndex
- forEach
- indexOf /
On Wed, Jul 18, 2018 at 5:44 PM, Cyril Auburtin
wrote:
> sorry you get 1, and need again to subtract the array length, `arr.length
-1
> - 1` to get the final result 3
So you can't just use the passed-in third argument, and need:
```js
let a = [7, 4, 6, 7, 12];
console.log(a.length - 1 -
I think it is irrelevant; the operator already exists and I would assume if
you want the negation of it you are using it correctly in the first place.
Otherwise are you not just arguing for its removal altogether? But to
answer your question one case that comes to mind is trapping get/has in a
I really like this possible new syntax for ranges:
```js
[2:9] // [2,3,4,5,6,7,8,9]
[1, 2, 4:7, 9] // [1, 2, 4, 5, 6, 7, 9]
[1:6:2] // [1, 3, 5]
```
Would someone in TC39 be up to champion this?
___
es-discuss mailing list
es-discuss@mozilla.org
20 matches
Mail list logo
