Re: Feature proposal

[Isiah Meadows]

I'm not a fan of the "Iteratable" object - it doesn't align with the
corresponding existing concept of "iterables", and the iterable
protocol is just an interface - there's no named object that
corresponds to that type.

What we really need is that pipeline operator to finally get figured
out: https://github.com/tc39/proposal-pipeline-operator

That wil address the primary need for things like these, without
running you into issues of namespace collision.

-

Isiah Meadows
m...@isiahmeadows.com
www.isiahmeadows.com


On Thu, Jul 19, 2018 at 11:38 AM, Nicolas B. Pierron
 wrote:
> On Thu, Jul 19, 2018 at 12:53 PM, Nicolas B. Pierron
>  wrote:
>>> On Wed, Jul 18, 2018 at 2:06 PM Nicolas B. Pierron
>>>  wrote:
 Stupid question, but why are some of these methods implemented on
 String, Array, TypedArray, Map and Set, while all of them are
 Iteratable?
>>>
>> Among list of nice Iteratable property that one might add, and which
>> might not be part of the standard are things like:
>>   chain, take, skip, takeWhile, skipWhile, repeat, zip, enumerate,
>> range, stepBy, …
>
> Apparently this already exists as a JS library:
> https://fitzgen.github.io/wu.js/
>
> --
> Nicolas B. Pierron
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Feature proposal

[Nicolas B. Pierron]

On Thu, Jul 19, 2018 at 12:53 PM, Nicolas B. Pierron
 wrote:
>> On Wed, Jul 18, 2018 at 2:06 PM Nicolas B. Pierron
>>  wrote:
>>> Stupid question, but why are some of these methods implemented on
>>> String, Array, TypedArray, Map and Set, while all of them are
>>> Iteratable?
>>
> Among list of nice Iteratable property that one might add, and which
> might not be part of the standard are things like:
>   chain, take, skip, takeWhile, skipWhile, repeat, zip, enumerate,
> range, stepBy, …

Apparently this already exists as a JS library:
https://fitzgen.github.io/wu.js/

-- 
Nicolas B. Pierron
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Feature proposal

[Mike Samuel]

On Thu, Jul 19, 2018 at 8:54 AM Nicolas B. Pierron <
nicolas.b.pier...@mozilla.com> wrote:

> On Wed, Jul 18, 2018 at 6:43 PM, Mike Samuel  wrote:
> > Reverse is problematic on String.  The index of a codepoint can't be
> > subtracted from String.length since length is not the count of
> codepoints.
>
> Don't take me wrong, I was not suggesting to add a `reverse` property.
> I was suggesting to add the Iteratable object in the prototype chain
> such that someone can implement extra property on the Iteratable /
> Iteratable.prototype object.
>

My mistake.  I assumed a goal was to allow implementing a generic
findLastIndex in
terms of find and reverse iterators.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Feature proposal

[Nicolas B. Pierron]

On Wed, Jul 18, 2018 at 6:43 PM, Mike Samuel  wrote:
> On Wed, Jul 18, 2018 at 2:06 PM Nicolas B. Pierron
>  wrote:
>> Stupid question, but why are some of these methods implemented on
>> String, Array, TypedArray, Map and Set, while all of them are
>> Iteratable?
>
>
> String is different from the others.
> The String index methods deal with a contiguous subsequence of the sequence,
> not the index of an element in the sequence.

I am not sure why this would prevent us from adding an Iteratable
object with common properties.  `Iteratable.prototype.foo` can exist
at the same time as `String.prototype.foo`, and calling the `foo`
property on a String will result in calling `String.prototype.foo`.

Also one could implement a naïve/default implementation of
`reverseOrder` which allocates a temporary array for object which have
no random accesses capabilities.


  Iteratable.prototype.reverseOrder = function* () {
  for (let e of [...this].reverse())
   yield e;
  }
```

>>
>> If we were to add all these methods on Iteratable, then one could add
>> a `reverse` generator property on Iteratable.
>
>
> Reverse is problematic on String.  The index of a codepoint can't be
> subtracted from String.length since length is not the count of codepoints.

Don't take me wrong, I was not suggesting to add a `reverse` property.
I was suggesting to add the Iteratable object in the prototype chain
such that someone can implement extra property on the Iteratable /
Iteratable.prototype object.

Among list of nice Iteratable property that one might add, and which
might not be part of the standard are things like:
  chain, take, skip, takeWhile, skipWhile, repeat, zip, enumerate,
range, stepBy, …

Another option would be to just add a property named `iter` which
returns an Iteratable object.

-- 
Nicolas B. Pierron
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Feature proposal

[Dmitry Shulgin]

Yeah, i meant  T.J. Crowder's comment that `reverseView` won't solve
original issue.

2018-07-19 12:34 GMT+03:00 Isiah Meadows :

> It shouldn't make anything that much more complex - the various Array
> methods are already generic.
>
>
> On Thu, Jul 19, 2018, 05:31 Dmitry Shulgin  wrote:
>
>> Cool, gonna read it out.
>> First impression -- it can make methods more complex and usage will be
>> different between `find`, `findlastIndex` etc., if we want to use something
>> like `reverseView`.
>>
>>
>> 2018-07-19 11:56 GMT+03:00 T.J. Crowder 
>> :
>>
>>> On Thu, Jul 19, 2018 at 9:49 AM, Isiah Meadows
>>>  wrote:
>>> > What about this alternate proposal:
>>>
>>> Great minds: https://esdiscuss.org/topic/fwd-feature-proposal#content-5
>>> ;-)
>>>
>>> -- T.J. Crowder
>>>
>>
>>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Feature proposal

[Dmitry Shulgin]

Cool, gonna read it out.
First impression -- it can make methods more complex and usage will be
different between `find`, `findlastIndex` etc., if we want to use something
like `reverseView`.

2018-07-19 11:56 GMT+03:00 T.J. Crowder :

> On Thu, Jul 19, 2018 at 9:49 AM, Isiah Meadows
>  wrote:
> > What about this alternate proposal:
>
> Great minds: https://esdiscuss.org/topic/fwd-feature-proposal#content-5
> ;-)
>
> -- T.J. Crowder
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Feature proposal

[Isiah Meadows]

I'd rather keep it restricted to very simple, context-free things like a
reverse subtract or single add, with only a few bits of data necessary.
Anything more is going to be a perf concern because you can't avoid visible
side effects.

On Thu, Jul 19, 2018, 05:03 Michael Luder-Rosefield 
wrote:

> This array view thing is very close to what I had in mind, and seems to
> suggest to a lot of interesting possibilities.
>
> What strikes me as the two most significant are:
>
>- again, 'reversed' is just one alternative iteration order through,
>though almost certainly the most useful
>- others I can think of could be 'even/odd indexes', 'random shuffle',
>   'iterate-until /while-condition', and filter equivalents
>- as well as the view defining the iteration order, it could define
>the computed value
>   - this would be basically a map where the value isn't computed
>   until accessed; caching behaviour could be user-determined
>
>
>
>
> On Thu, 19 Jul 2018 at 09:49 Isiah Meadows  wrote:
>
>> What about this alternate proposal:
>>
>>
>> https://github.com/isiahmeadows/array-additions-proposal/blob/master/README.md#get-arrayprototypereversed-get-typedarrayprototypereversed
>>
>> (I've got a myriad of other related stuff there, too.)
>>
>>
>> On Thu, Jul 19, 2018, 04:41 Dmitry Shulgin  wrote:
>>
>>> Above we was talking about this.
>>> consistency and handy using -- two main reasons for this proposal.
>>>
>>> `reverse` will also mutate my array, cause of in-place implementation.
>>>
>>> You can find workaround for many existing methods, but it's not handy to
>>> my mind.
>>>
>> ___
>> 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

Re: Feature proposal

[Michael Luder-Rosefield]

This array view thing is very close to what I had in mind, and seems to
suggest to a lot of interesting possibilities.

What strikes me as the two most significant are:

   - again, 'reversed' is just one alternative iteration order through,
   though almost certainly the most useful
   - others I can think of could be 'even/odd indexes', 'random shuffle',
  'iterate-until /while-condition', and filter equivalents
   - as well as the view defining the iteration order, it could define the
   computed value
  - this would be basically a map where the value isn't computed until
  accessed; caching behaviour could be user-determined




On Thu, 19 Jul 2018 at 09:49 Isiah Meadows  wrote:

> What about this alternate proposal:
>
>
> https://github.com/isiahmeadows/array-additions-proposal/blob/master/README.md#get-arrayprototypereversed-get-typedarrayprototypereversed
>
> (I've got a myriad of other related stuff there, too.)
>
>
> On Thu, Jul 19, 2018, 04:41 Dmitry Shulgin  wrote:
>
>> Above we was talking about this.
>> consistency and handy using -- two main reasons for this proposal.
>>
>> `reverse` will also mutate my array, cause of in-place implementation.
>>
>> You can find workaround for many existing methods, but it's not handy to
>> my mind.
>>
> ___
> 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

Re: Feature proposal

[T.J. Crowder]

On Thu, Jul 19, 2018 at 9:49 AM, Isiah Meadows
 wrote:
> What about this alternate proposal:

Great minds: https://esdiscuss.org/topic/fwd-feature-proposal#content-5 ;-)

-- T.J. Crowder
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Feature proposal

[Isiah Meadows]

What about this alternate proposal:

https://github.com/isiahmeadows/array-additions-proposal/blob/master/README.md#get-arrayprototypereversed-get-typedarrayprototypereversed

(I've got a myriad of other related stuff there, too.)

On Thu, Jul 19, 2018, 04:41 Dmitry Shulgin  wrote:

> Above we was talking about this.
> consistency and handy using -- two main reasons for this proposal.
>
> `reverse` will also mutate my array, cause of in-place implementation.
>
> You can find workaround for many existing methods, but it's not handy to
> my mind.
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Feature proposal

[Dmitry Shulgin]

Above we was talking about this.
consistency and handy using -- two main reasons for this proposal.

`reverse` will also mutate my array, cause of in-place implementation.

You can find workaround for many existing methods, but it's not handy to my
mind.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Feature proposal

[Isiah Meadows]

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  wrote:
>
>
> On Wed, Jul 18, 2018 at 2:06 PM Nicolas B. Pierron
>  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 / reduceRight
>> > some
>> >
>> > which is not very consistent at all. Perhaps we could add an `iterOrder`
>> > method that changes the way the array is iterated through?
>>
>> Stupid question, but why are some of these methods implemented on
>> String, Array, TypedArray, Map and Set, while all of them are
>> Iteratable?
>
>
> String is different from the others.
> The String index methods deal with a contiguous subsequence of the sequence,
> not the index of an element in the sequence.
>
>>
>> If we were to add all these methods on Iteratable, then one could add
>> a `reverse` generator property on Iteratable.
>
>
> Reverse is problematic on String.  The index of a codepoint can't be
> subtracted from String.length since length is not the count of codepoints.
>
>>
>>   Iteratable.prototype.reverse = function* reverse() { … };
>>   foo.reverse().forEach( e => console.log(e) )
>>
>> Though, this implies that all these objects implement the Iteratable
>> prototype, and I am not sure what impact this might have on the Web.
>
>
>
>
>
>> --
>> Nicolas B. Pierron
>> ___
>> 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
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Feature proposal

[Mike Samuel]

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 / reduceRight
> > some
> >
> > which is not very consistent at all. Perhaps we could add an `iterOrder`
> > method that changes the way the array is iterated through?
>
> Stupid question, but why are some of these methods implemented on
> String, Array, TypedArray, Map and Set, while all of them are
> Iteratable?
>

String is different from the others.
The String index methods deal with a contiguous subsequence of the
sequence, not the index of an element in the sequence.


> If we were to add all these methods on Iteratable, then one could add
> a `reverse` generator property on Iteratable.
>

Reverse is problematic on String.  The index of a codepoint can't be
subtracted from String.length since length is not the count of codepoints.


>   Iteratable.prototype.reverse = function* reverse() { … };
>   foo.reverse().forEach( e => console.log(e) )
>
> Though, this implies that all these objects implement the Iteratable
> prototype, and I am not sure what impact this might have on the Web.
>




-- 
> Nicolas B. Pierron
> ___
> 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

Feature proposal

[Dmitry Shulgin]

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
it's a handy way to perform these examples.
Looks more universal than handy to me.

I like the idea to expand this proposal for
`find` method as well.

Thanks.

P. S. This is my first proposal, so I apologies for bad formatting and
forwarding.

On Wed, 18 Jul 2018, 20:32 ,  wrote:

> Send es-discuss mailing list submissions to
> es-discuss@mozilla.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mail.mozilla.org/listinfo/es-discuss
> or, via email, send a message with subject or body 'help' to
> es-discuss-requ...@mozilla.org
>
> You can reach the person managing the list at
> es-discuss-ow...@mozilla.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of es-discuss digest..."
> Today's Topics:
>
>1. Re: Ranges (Cyril Auburtin)
>    2. Re: Feature proposal (T.J. Crowder)
>3. Re: Feature proposal (Michael Luder-Rosefield)
>
>
>
> -- Forwarded message --
> From: Cyril Auburtin 
> To: es-discuss 
> Cc:
> Bcc:
> Date: Wed, 18 Jul 2018 18:48:11 +0200
> Subject: Re: Ranges
> 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?
>
>
>
> -- Forwarded message --
> From: "T.J. Crowder" 
> To: Cyril Auburtin 
> Cc: es-discuss 
> Bcc:
> Date: Wed, 18 Jul 2018 18:04:25 +0100
> Subject: Re: Feature proposal
> 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 - a.findIndex((_, i) =>
> isPrime(a[a.length-1-i])));
> ```
>
> Strikes me as a reasonable argument for adding `findLastIndex`. ;-) (And
> perhaps `findLast`, since the same trick with `find` just won't work at
> all.)
>
> Prior art (looking for instance at the libs that inspired the array
> additions in ES5 and ES2015):
> * Lodash implements both `findLastIndex` and `findLast`).
> * Underscore, PrototypeJS, and MooTools don't as far as I can see from the
> docs.
>
> -- T.J. Crowder
>
>
>
> -- Forwarded message --
> From: Michael Luder-Rosefield 
> To: Cyril Auburtin 
> Cc: es-discuss 
> Bcc:
> Date: Wed, 18 Jul 2018 18:31:41 +0100
> Subject: Re: Feature proposal
> 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 / lastIndexOf
>- map
>- reduce / reduceRight
>- some
>
> which is not very consistent at all. Perhaps we could add an `iterOrder`
> method that changes the way the array is iterated through?
>
> I propose it could take 1 parameter:
>
>- If -1 is passed in, the array is iterated through in reverse.
>- If 1,0 or undefined is passed through, the array is iterated through
>normally.
>- If an array of numbers is passed through, these represent the
>indexes in the order they will be processed.
>- Any illegible indexes in the passed-in array will be ignored
>   - Any eligible indexes not given will be ignored
>- If a generator function is passed in, it should take the array (or a
>length value) and spit out indexes.
>- If a non-generator function is passed in, it should spit out an
>array of indexes, which will be used as-per arrays being passed in
>
> Whether that iterOrder is reset after an iteration could go either way.
> I'd suggest it probably should, with an option to persist.
>
> Example:
>
> ```
> let arr = [ 8,4,7,3 ];
>
> arr.iterOrder().map(x => x) === arr
> arr.iterOrder(-1).map(x => x) === arr.reverse() === [ 3,7,4,8 ]
> arr.iterOrder([ 2,1 ]).map(x => x) === [ 7,4 ]
> // haven't got time to give function arg examples, but randomisers would
> be fairly trivial
>
> // original indexes are preserved during iteration:
> arr.iterOrder(-1).forEach((val, i) => cons

Re: Feature proposal

[Nicolas B. Pierron]

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 the way the array is iterated through?

Stupid question, but why are some of these methods implemented on
String, Array, TypedArray, Map and Set, while all of them are
Iteratable?
If we were to add all these methods on Iteratable, then one could add
a `reverse` generator property on Iteratable.

  Iteratable.prototype.reverse = function* reverse() { … };
  foo.reverse().forEach( e => console.log(e) )

Though, this implies that all these objects implement the Iteratable
prototype, and I am not sure what impact this might have on the Web.

-- 
Nicolas B. Pierron
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Feature proposal

[T.J. Crowder]

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 a similar thought. We're talking arrays, not generic iterables,
after all.

My thought was some kind of reversed view of the array, something like this:

```js
const reversedView = array => new Proxy(array, {
get(target, prop, receiver) {
if (isArrayIndex(prop)) {
prop = target.length - 1 - prop;
}
return Reflect.get(target, prop, receiver);
}
});
```

...but thought-through, tested, and efficient (which the above Is Not -- it
does work in a basic couple of checks, but I'm running out the door and
wouldn't be surprised if there are edge cases not handled:
http://jsfiddle.net/80se3xqj/). Then my mind sort of wanders off wanting to
generalize this concept of a view on an array... :-)

Amusingly, this doesn't help at all with the original request here:
`findLastIndex` (because it would return the index in the reversed view,
not the original array). But it does with `forEach`, `find`, `some`, etc.:

```js
const objects = [
{id: 1, type: 1},
{id: 2, type: 2},
{id: 3, type: 2},
{id: 4, type: 3}
];
console.log(reversedView(objects).find(o => o.type === 2));
```

Finds `{id: 3, type: 2}`.

-- T.J. Crowder
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Feature proposal

[Michael Luder-Rosefield]

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 / lastIndexOf
   - map
   - reduce / reduceRight
   - some

which is not very consistent at all. Perhaps we could add an `iterOrder`
method that changes the way the array is iterated through?

I propose it could take 1 parameter:

   - If -1 is passed in, the array is iterated through in reverse.
   - If 1,0 or undefined is passed through, the array is iterated through
   normally.
   - If an array of numbers is passed through, these represent the indexes
   in the order they will be processed.
   - Any illegible indexes in the passed-in array will be ignored
  - Any eligible indexes not given will be ignored
   - If a generator function is passed in, it should take the array (or a
   length value) and spit out indexes.
   - If a non-generator function is passed in, it should spit out an array
   of indexes, which will be used as-per arrays being passed in

Whether that iterOrder is reset after an iteration could go either way. I'd
suggest it probably should, with an option to persist.

Example:

```
let arr = [ 8,4,7,3 ];

arr.iterOrder().map(x => x) === arr
arr.iterOrder(-1).map(x => x) === arr.reverse() === [ 3,7,4,8 ]
arr.iterOrder([ 2,1 ]).map(x => x) === [ 7,4 ]
// haven't got time to give function arg examples, but randomisers would be
fairly trivial

// original indexes are preserved during iteration:
arr.iterOrder(-1).forEach((val, i) => console.log(val, i))
// > 3, 3
// > 7, 2
// > 4, 1
// > 8, 0
```

This is a messy first-pass at the problem, and I can already see potential
issues, but it would at least standardise and generalise the problem



On Wed, 18 Jul 2018 at 17:44 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
>
> 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 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
>>> 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
>>> *function.
>>> I was thinking:
>>> Why do we have *findIndex*` method, but no *findLastIndex*?
>>> It seems logical to follow *[index|lastIndex]Of* pair, doesn't it?
>>> Reversing array in this case seems too complicated to me.
>>>
>>> So, i would like to suggest new method like
>>> *Array.prototype.findLastIndex()*
>>>
>>> Example:
>>>
>>> function isPrime(element, index, array) {
>>>   var start = 2;
>>>   while (start <= Math.sqrt(element)) {
>>> if (element % start++ < 1) {
>>>   return false;
>>> }
>>>   }
>>>   return element > 1;
>>> }
>>>
>>> console.log([4, 6, 8, 12].findIndex(isPrime)); // -1, not found
>>> console.log([7, 4, 6, 7, 12].findIndexLast(isPrime)); // 3
>>>
>>>
>>> Would be glad to implement, if it makes sense.
>>>
>>> Thx for replies.
>>>
>>> P.S. Small issue on GitHub was closed due to offtop (not an issue, as i
>>> understand).
>>> https://github.com/tc39/ecma262/issues/1253
>>>
>>> ___
>>> 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
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Feature proposal

[T.J. Crowder]

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 - a.findIndex((_, i) => isPrime(a[a.length-1-i])));
```

Strikes me as a reasonable argument for adding `findLastIndex`. ;-) (And
perhaps `findLast`, since the same trick with `find` just won't work at
all.)

Prior art (looking for instance at the libs that inspired the array
additions in ES5 and ES2015):
* Lodash implements both `findLastIndex` and `findLast`).
* Underscore, PrototypeJS, and MooTools don't as far as I can see from the
docs.

-- T.J. Crowder
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Feature proposal

[Cyril Auburtin]

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 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
>> 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
>> *function.
>> I was thinking:
>> Why do we have *findIndex*` method, but no *findLastIndex*?
>> It seems logical to follow *[index|lastIndex]Of* pair, doesn't it?
>> Reversing array in this case seems too complicated to me.
>>
>> So, i would like to suggest new method like
>> *Array.prototype.findLastIndex()*
>>
>> Example:
>>
>> function isPrime(element, index, array) {
>>   var start = 2;
>>   while (start <= Math.sqrt(element)) {
>> if (element % start++ < 1) {
>>   return false;
>> }
>>   }
>>   return element > 1;
>> }
>>
>> console.log([4, 6, 8, 12].findIndex(isPrime)); // -1, not found
>> console.log([7, 4, 6, 7, 12].findIndexLast(isPrime)); // 3
>>
>>
>> Would be glad to implement, if it makes sense.
>>
>> Thx for replies.
>>
>> P.S. Small issue on GitHub was closed due to offtop (not an issue, as i
>> understand).
>> https://github.com/tc39/ecma262/issues/1253
>>
>> ___
>> 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

Re: Feature proposal

[Cyril Auburtin]

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
> 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 *
> function.
> I was thinking:
> Why do we have *findIndex*` method, but no *findLastIndex*?
> It seems logical to follow *[index|lastIndex]Of* pair, doesn't it?
> Reversing array in this case seems too complicated to me.
>
> So, i would like to suggest new method like
> *Array.prototype.findLastIndex()*
>
> Example:
>
> function isPrime(element, index, array) {
>   var start = 2;
>   while (start <= Math.sqrt(element)) {
> if (element % start++ < 1) {
>   return false;
> }
>   }
>   return element > 1;
> }
>
> console.log([4, 6, 8, 12].findIndex(isPrime)); // -1, not found
> console.log([7, 4, 6, 7, 12].findIndexLast(isPrime)); // 3
>
>
> Would be glad to implement, if it makes sense.
>
> Thx for replies.
>
> P.S. Small issue on GitHub was closed due to offtop (not an issue, as i
> understand).
> https://github.com/tc39/ecma262/issues/1253
>
> ___
> 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

Fwd: Feature proposal

[Dmitry Shulgin]

-- 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 *
function.
I was thinking:
Why do we have *findIndex*` method, but no *findLastIndex*?
It seems logical to follow *[index|lastIndex]Of* pair, doesn't it?
Reversing array in this case seems too complicated to me.

So, i would like to suggest new method like
*Array.prototype.findLastIndex()*

Example:

function isPrime(element, index, array) {
  var start = 2;
  while (start <= Math.sqrt(element)) {
if (element % start++ < 1) {
  return false;
}
  }
  return element > 1;
}

console.log([4, 6, 8, 12].findIndex(isPrime)); // -1, not found
console.log([7, 4, 6, 7, 12].findIndexLast(isPrime)); // 3


Would be glad to implement, if it makes sense.

Thx for replies.

P.S. Small issue on GitHub was closed due to offtop (not an issue, as i
understand).
https://github.com/tc39/ecma262/issues/1253
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Feature Proposal - async variables (like thread local storage from C)

[Guy Margalit]

Yes, it is. Thanks for referring me to the right point. Anything I can do
to help advance that proposal?

On Mar 11, 2018 5:40 PM, "Thomas Grainger"  wrote:

I'm pretty sure this is Zones

On 11 Mar 2018 15:35, "Guy Margalit"  wrote:

> Hey
>
> It's my first attempt to contribute to ECMAScript so would love your
> feedback if I better off change how I go about it.
>
> The problem I want to highlight is that besides argument passing it is
> impossible to have any information associated with a flow of async code as
> any async code will create its own context and will only get the arguments
> passed to it from its caller.
>
> A simple use case for information that is not easy to pass as arguments is
> "transaction ID" where unique IDs are generated at the beginning of a
> transaction, and propagate that ID to any function that is being called as
> part of that transaction.
>
> However as a javascript codebase grows, it becomes hard to introduce new
> project-wide information such as transaction ID when the only mechanism to
> pass such information is function argument passing, and this becomes
> impossible as many times you are using other libraries of code inside the
> code stack, and one cannot change all the code just to add arguments.
>
> Few examples:
>
>- Identify HTTP requests and print that a request ID in every log
>print that was fan-out from that request.
>- Find how many database calls one async flow created.
>- Keep pools of resources (buffers / connections / tokens) per request.
>
> In C/C++ one can use thread local storage (
> https://en.wikipedia.org/wiki/Thread-local_storage) to keep information
> that automatically switches with the threads context switch.
>
> I imagine a similar mechanism, in the spirit of javascript - define a
> variable as `async`:
>
> ```
> async var name = ;
> ```
>
> Async variables will be saved and restored automatically when the context
> is resumed. It should probably have a more precise definition in ECMAScript
> terms.
>
> ```
> async var reqid = '';
>
> http_server.on('request', handler);
>
> async function handler(req, res) => {
>
>   // setting async variable concurrently be different requests
>   // will retain the generated value for the other calls made by this
> context (sync or async).
>   reqid = `REQ-${uuid()}`;
>
>   await load_data_from_db(req);
>   await send_analytics_info(req);
>   send_reply(res);
> });
>
> async function load_data_from_db(req) {
>   console.log(`${reqid} load_data_from_db`);
>   try {
>  ...
>   } catch (err) {
> ...
> if (err.code === 'ACCESS_DENIED') {
>   console.log(`${reqid} ACCESS_DENIED. this incident will be reported.
> `);
> }
>   }
> }
>
> async function send_analytics_info(req) {
>   console.log(`${reqid} send_analytics_info`);
>   ...
>   analytics.send(reqid, ...);
>   ...
> }
>
> function send_reply(res) {
>   console.log(`${reqid} send_analytics_info`);
>   ...
>   res.setHeader('reqid', reqid); // for supportability
>   res.send(...);
>   ...
> }
> ```
>
> Technically speaking, async variables should be replaced whenever there is
> a context switch - either when a sync stack returns to the top stack
> level, or when an async function returns from await.
>
> However, this means that every registration of a function for later, such
> as setTimeout(func), should also keep the async variables which sounds
> difficult.
>
> Would be great to hear if you think this is valuable and feasible, or
> maybe there's a way to design this with less overhead.
>
> Thanks,
> Guy Margalit
>
>
> ___
> 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

Re: Feature Proposal - async variables (like thread local storage from C)

[Thomas Grainger]

I'm pretty sure this is Zones

On 11 Mar 2018 15:35, "Guy Margalit"  wrote:

> Hey
>
> It's my first attempt to contribute to ECMAScript so would love your
> feedback if I better off change how I go about it.
>
> The problem I want to highlight is that besides argument passing it is
> impossible to have any information associated with a flow of async code as
> any async code will create its own context and will only get the arguments
> passed to it from its caller.
>
> A simple use case for information that is not easy to pass as arguments is
> "transaction ID" where unique IDs are generated at the beginning of a
> transaction, and propagate that ID to any function that is being called as
> part of that transaction.
>
> However as a javascript codebase grows, it becomes hard to introduce new
> project-wide information such as transaction ID when the only mechanism to
> pass such information is function argument passing, and this becomes
> impossible as many times you are using other libraries of code inside the
> code stack, and one cannot change all the code just to add arguments.
>
> Few examples:
>
>- Identify HTTP requests and print that a request ID in every log
>print that was fan-out from that request.
>- Find how many database calls one async flow created.
>- Keep pools of resources (buffers / connections / tokens) per request.
>
> In C/C++ one can use thread local storage (https://en.wikipedia.org/wiki
> /Thread-local_storage) to keep information that automatically switches
> with the threads context switch.
>
> I imagine a similar mechanism, in the spirit of javascript - define a
> variable as `async`:
>
> ```
> async var name = ;
> ```
>
> Async variables will be saved and restored automatically when the context
> is resumed. It should probably have a more precise definition in ECMAScript
> terms.
>
> ```
> async var reqid = '';
>
> http_server.on('request', handler);
>
> async function handler(req, res) => {
>
>   // setting async variable concurrently be different requests
>   // will retain the generated value for the other calls made by this
> context (sync or async).
>   reqid = `REQ-${uuid()}`;
>
>   await load_data_from_db(req);
>   await send_analytics_info(req);
>   send_reply(res);
> });
>
> async function load_data_from_db(req) {
>   console.log(`${reqid} load_data_from_db`);
>   try {
>  ...
>   } catch (err) {
> ...
> if (err.code === 'ACCESS_DENIED') {
>   console.log(`${reqid} ACCESS_DENIED. this incident will be reported.
> `);
> }
>   }
> }
>
> async function send_analytics_info(req) {
>   console.log(`${reqid} send_analytics_info`);
>   ...
>   analytics.send(reqid, ...);
>   ...
> }
>
> function send_reply(res) {
>   console.log(`${reqid} send_analytics_info`);
>   ...
>   res.setHeader('reqid', reqid); // for supportability
>   res.send(...);
>   ...
> }
> ```
>
> Technically speaking, async variables should be replaced whenever there is
> a context switch - either when a sync stack returns to the top stack
> level, or when an async function returns from await.
>
> However, this means that every registration of a function for later, such
> as setTimeout(func), should also keep the async variables which sounds
> difficult.
>
> Would be great to hear if you think this is valuable and feasible, or
> maybe there's a way to design this with less overhead.
>
> Thanks,
> Guy Margalit
>
>
> ___
> 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

Feature Proposal - async variables (like thread local storage from C)

[Guy Margalit]

Hey

It's my first attempt to contribute to ECMAScript so would love your
feedback if I better off change how I go about it.

The problem I want to highlight is that besides argument passing it is
impossible to have any information associated with a flow of async code as
any async code will create its own context and will only get the arguments
passed to it from its caller.

A simple use case for information that is not easy to pass as arguments is
"transaction ID" where unique IDs are generated at the beginning of a
transaction, and propagate that ID to any function that is being called as
part of that transaction.

However as a javascript codebase grows, it becomes hard to introduce new
project-wide information such as transaction ID when the only mechanism to
pass such information is function argument passing, and this becomes
impossible as many times you are using other libraries of code inside the
code stack, and one cannot change all the code just to add arguments.

Few examples:

   - Identify HTTP requests and print that a request ID in every log print
   that was fan-out from that request.
   - Find how many database calls one async flow created.
   - Keep pools of resources (buffers / connections / tokens) per request.

In C/C++ one can use thread local storage (https://en.wikipedia.org/
wiki/Thread-local_storage) to keep information that automatically switches
with the threads context switch.

I imagine a similar mechanism, in the spirit of javascript - define a
variable as `async`:

```
async var name = ;
```

Async variables will be saved and restored automatically when the context
is resumed. It should probably have a more precise definition in ECMAScript
terms.

```
async var reqid = '';

http_server.on('request', handler);

async function handler(req, res) => {

  // setting async variable concurrently be different requests
  // will retain the generated value for the other calls made by this
context (sync or async).
  reqid = `REQ-${uuid()}`;

  await load_data_from_db(req);
  await send_analytics_info(req);
  send_reply(res);
});

async function load_data_from_db(req) {
  console.log(`${reqid} load_data_from_db`);
  try {
 ...
  } catch (err) {
...
if (err.code === 'ACCESS_DENIED') {
  console.log(`${reqid} ACCESS_DENIED. this incident will be reported.
`);
}
  }
}

async function send_analytics_info(req) {
  console.log(`${reqid} send_analytics_info`);
  ...
  analytics.send(reqid, ...);
  ...
}

function send_reply(res) {
  console.log(`${reqid} send_analytics_info`);
  ...
  res.setHeader('reqid', reqid); // for supportability
  res.send(...);
  ...
}
```

Technically speaking, async variables should be replaced whenever there is
a context switch - either when a sync stack returns to the top stack level,
or when an async function returns from await.

However, this means that every registration of a function for later, such
as setTimeout(func), should also keep the async variables which sounds
difficult.

Would be great to hear if you think this is valuable and feasible, or maybe
there's a way to design this with less overhead.

Thanks,
Guy Margalit
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss