Re: Feature proposal
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: JSON support for BigInt in Chrome/V8
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' fails.
> if everything is translated to bigint the calc for 'c' fails.
I think you missed my point: I'm suggesting an extra option to where
floats are parsed differently from integers.
```js
// JSON
{"a": 123.0, "b": 123}
// Parsed normally
{a: 123, b: 123}
// Parsed with option
{a: 123, b: 123n}
```
So given this, the test would be exactly what's expected with the option.
-
Isiah Meadows
m...@isiahmeadows.com
www.isiahmeadows.com
On Wed, Jul 18, 2018 at 5:03 AM, J Decker wrote:
>
>
> 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 the spec (maybe an optional built-in
>> module).
>>
>> I've in the past few months seen similar things come up a few times
>> already. I like the idea of a built-in schema-based JSON validator +
>> parser (it'd be faster than what we currently have), but most things
>> out there suck in some way, mostly just being boilerplatey, and
>> there's a lot of design work to get out of the way first before you
>> can come up with something that doesn't.
>>
>> But as it stands, the only things I'd support for the `JSON` global itself
>> are:
>>
>> 1. Adding separate prototypes for `JSON.stringify(source, options)`
>> and `JSON.parse(source, options)`, so it's easier to extend and
>> comprehend the arguments.
>> 2. Adding an option to parse anything consisting of purely digits (no
>> exponent or decimal) as a BigInt, regardless of size.
>
> 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' fails.
> if everything is translated to bigint the calc for 'c' fails.
>
>> 3. Adding an option to stringify BigInts into integer-only numbers and
>> normal numbers into unconditional floats.
>>
>
>
>>
>> These could be either separate methods or part of a 4th options argument.
>>
>
> 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.
>
> Although I would like to see a better method than eval() to translate the
> input string from JSON for say { d : 123n }; right now within JS I'd have to
> use EVAL; in V8 I could just create a BigInt::new()
>
> (and RE: eval, not saying it's a GOOD solution; it's just apparently the
> only solution ATM; other than splicing the string.)
>
>>
>> -
>>
>> Isiah Meadows
>> m...@isiahmeadows.com
>> www.isiahmeadows.com
>>
>>
>> On Tue, Jul 17, 2018 at 6:52 PM, Michael J. Ryan
>> wrote:
>> > Out of bounds as you'd still have to parse it, but for encoding, could
>> > add
>> > BigInt.prototype.toJSON ...
>> >
>> > On Tue, Jul 17, 2018, 15:44 Andrea Giammarchi
>> >
>> > wrote:
>> >>
>> >> I guess a better example would've been `Boolean('false')` returns true,
>> >> but yeah, I've moved slightly forward already with everything, if you
>> >> read
>> >> other messages.
>> >>
>> >> Regards.
>> >>
>> >> On Wed, Jul 18, 2018 at 12:06 AM Waldemar Horwat
>> >> wrote:
>> >>>
>> >>> On 07/17/2018 04:27 AM, Andrea Giammarchi wrote:
>> >>> > actually, never mind ... but I find it hilarious that
>> >>> > BigInt('55501') works but
>> >>> > BigInt('55501n') doesn't ^_^;;
>> >>>
>> >>> That's no different from how other built-in types work.
>> >>> String('"foo"')
>> >>> doesn't give you the same string as the string literal "foo".
>> >>>
>> >>> Waldemar
>> >>
>> >> ___
>> >> 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
>
>
> ___
> 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: JSON support for BigInt in Chrome/V8
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 Programming Language, Standard ECMA-262 3rd Edition - December 1999." ECMA-404 states: "JSON stands for JavaScript Object Notation and was inspired by the object literals of JavaScript aka ECMAScript as defined in the ECMAScript Language Specification, Third Edition [1]. However, it does not attempt to impose ECMAScript’s internal data representations on other programming languages. Instead, it shares a small subset of ECMAScript’s syntax with all other programming languages." The 3rd edition did not contain the 'n' suffix, and neither indicate that new ES features should be added to JSON. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Feature proposal
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
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) => 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 à
Re: Feature proposal
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
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: es-discuss Digest, Vol 137, Issue 46
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) => 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 >>
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) => 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
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: 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? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: 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 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
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: Small Proposal "!in"
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 altogether? But
> to answer your question one case that comes to mind is trapping get/has in
> a proxy handler.
Why should we assume that only people who consistently use `in` correctly
would want the negation? It seems that people who use it incorrectly
because they are confused about the precise semantics or don't care might
want the negation too. If there are more of the latter then we should not
assume what you assume.
Proxy handler code is important, but very few developers will ever write a
proxy handler over their careers, so this seems like a marginal use case.
Besides, Reflect.has is probably a better choice in a proxy handler.
I am not arguing for removing `in`. That would break the web. I am just
arguing for prioritizing changes that provide features that more closely
match the semantics developers typically want over making it more
convenient to write code that seems to work in casual testing but has
subtly wrong semantics.
> On Wednesday, July 18, 2018, Mike Samuel wrote:
>
>>
>>
>> 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 to use !(a in b), not
>>> !hasOwnProperty.
>>>
>>
>> Why should we assume the developer is using `in` correctly?
>> Apologies if I buried my question at the end. It was, what are the use
>> cases for `in` that would not be better served by an ergonomic, infix
>> hasOwnProperty?
>>
>>
>> Same reason we don't use...
>>> !(a == b) // a != b
>>> !(a === b) // a !== b
>>>
>>
>>
>>> !(a > b) // a <= b
>>> (!(a > b) && !(a == b)) // a < b
>>>
>>
>> I'm not sure this is relevant to your larger point, and I've already
>> conceded ergonomics, but
>> these last two are not equivalent because NaN is weird.
>>
>> a = NaN, b = 0
>> [!(a > b), a <= b] // [true, false]
>> [!(a > b) && !(a == b), a < b] // [true, false]
>>
>>
>>
>>
>>
>>> On Thursday, June 28, 2018, Tobias Buschor
>>> wrote:
>>>
I dont like to write:
if ( !('x' in obj) && !('y' in obj) ) {
doit()
}
I was even tempted to write it that way:
if ('x' in obj || 'y' in obj) { } else {
doit()
}
What about a !in operator to write it like this?
if ('x' !in obj && 'y' !in obj) {
doit()
}
___
>>> 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: Small Proposal "!in"
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
proxy handler.
On Wednesday, July 18, 2018, Mike Samuel wrote:
>
>
> 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 to use !(a in b), not
>> !hasOwnProperty.
>>
>
> Why should we assume the developer is using `in` correctly?
> Apologies if I buried my question at the end. It was, what are the use
> cases for `in` that would not be better served by an ergonomic, infix
> hasOwnProperty?
>
>
> Same reason we don't use...
>> !(a == b) // a != b
>> !(a === b) // a !== b
>>
>
>
>> !(a > b) // a <= b
>> (!(a > b) && !(a == b)) // a < b
>>
>
> I'm not sure this is relevant to your larger point, and I've already
> conceded ergonomics, but
> these last two are not equivalent because NaN is weird.
>
> a = NaN, b = 0
> [!(a > b), a <= b] // [true, false]
> [!(a > b) && !(a == b), a < b] // [true, false]
>
>
>
>
>
>> On Thursday, June 28, 2018, Tobias Buschor
>> wrote:
>>
>>> I dont like to write:
>>> if ( !('x' in obj) && !('y' in obj) ) {
>>> doit()
>>> }
>>>
>>> I was even tempted to write it that way:
>>> if ('x' in obj || 'y' in obj) { } else {
>>> doit()
>>> }
>>>
>>> What about a !in operator to write it like this?
>>> if ('x' !in obj && 'y' !in obj) {
>>> doit()
>>> }
>>>
>>> ___
>> 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: Small Proposal "!in"
[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 would make infix `in` unrestricted but the negation restricted. x // no semicolon inserted in (obj) x // semicolon inserted !n (obj) Not a blocker, but worth keeping in mind. I also have to look hard at them to distinguish. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Small Proposal "!in"
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 to use !(a in b), not
> !hasOwnProperty.
>
Why should we assume the developer is using `in` correctly?
Apologies if I buried my question at the end. It was, what are the use
cases for `in` that would not be better served by an ergonomic, infix
hasOwnProperty?
Same reason we don't use...
> !(a == b) // a != b
> !(a === b) // a !== b
>
> !(a > b) // a <= b
> (!(a > b) && !(a == b)) // a < b
>
I'm not sure this is relevant to your larger point, and I've already
conceded ergonomics, but
these last two are not equivalent because NaN is weird.
a = NaN, b = 0
[!(a > b), a <= b] // [true, false]
[!(a > b) && !(a == b), a < b] // [true, false]
> On Thursday, June 28, 2018, Tobias Buschor
> wrote:
>
>> I dont like to write:
>> if ( !('x' in obj) && !('y' in obj) ) {
>> doit()
>> }
>>
>> I was even tempted to write it that way:
>> if ('x' in obj || 'y' in obj) { } else {
>> doit()
>> }
>>
>> What about a !in operator to write it like this?
>> if ('x' !in obj && 'y' !in obj) {
>> doit()
>> }
>>
>> ___
> 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
Small Proposal "!in"
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) // a !== b
!(a > b) // a <= b
(!(a > b) && !(a == b)) // a < b
On Thursday, June 28, 2018, Tobias Buschor wrote:
> I dont like to write:
> if ( !('x' in obj) && !('y' in obj) ) {
> doit()
> }
>
> I was even tempted to write it that way:
> if ('x' in obj || 'y' in obj) { } else {
> doit()
> }
>
> What about a !in operator to write it like this?
> if ('x' !in obj && 'y' !in obj) {
> doit()
> }
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Fwd: Feature proposal
-- 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: JSON support for BigInt in Chrome/V8
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 the spec (maybe an optional built-in
> module).
>
> I've in the past few months seen similar things come up a few times
> already. I like the idea of a built-in schema-based JSON validator +
> parser (it'd be faster than what we currently have), but most things
> out there suck in some way, mostly just being boilerplatey, and
> there's a lot of design work to get out of the way first before you
> can come up with something that doesn't.
>
> But as it stands, the only things I'd support for the `JSON` global itself
> are:
>
> 1. Adding separate prototypes for `JSON.stringify(source, options)`
> and `JSON.parse(source, options)`, so it's easier to extend and
> comprehend the arguments.
> 2. Adding an option to parse anything consisting of purely digits (no
> exponent or decimal) as a BigInt, regardless of size.
>
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' fails.
if everything is translated to bigint the calc for 'c' fails.
3. Adding an option to stringify BigInts into integer-only numbers and
> normal numbers into unconditional floats.
>
>
> These could be either separate methods or part of a 4th options argument.
>
>
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.
Although I would like to see a better method than eval() to translate the
input string from JSON for say { d : 123n }; right now within JS I'd have
to use EVAL; in V8 I could just create a BigInt::new()
(and RE: eval, not saying it's a GOOD solution; it's just apparently the
only solution ATM; other than splicing the string.)
> -
>
> Isiah Meadows
> m...@isiahmeadows.com
> www.isiahmeadows.com
>
>
> On Tue, Jul 17, 2018 at 6:52 PM, Michael J. Ryan
> wrote:
> > Out of bounds as you'd still have to parse it, but for encoding, could
> add
> > BigInt.prototype.toJSON ...
> >
> > On Tue, Jul 17, 2018, 15:44 Andrea Giammarchi <
> andrea.giammar...@gmail.com>
> > wrote:
> >>
> >> I guess a better example would've been `Boolean('false')` returns true,
> >> but yeah, I've moved slightly forward already with everything, if you
> read
> >> other messages.
> >>
> >> Regards.
> >>
> >> On Wed, Jul 18, 2018 at 12:06 AM Waldemar Horwat
> >> wrote:
> >>>
> >>> On 07/17/2018 04:27 AM, Andrea Giammarchi wrote:
> >>> > actually, never mind ... but I find it hilarious that
> >>> > BigInt('55501') works but
> >>> > BigInt('55501n') doesn't ^_^;;
> >>>
> >>> That's no different from how other built-in types work.
> String('"foo"')
> >>> doesn't give you the same string as the string literal "foo".
> >>>
> >>> Waldemar
> >>
> >> ___
> >> 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
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
