FWIW another disadvantage is that operators cannot be polyfilled, so it'll
take forever for those not using transpilers to adopt these, while having a
`Math,mod` would work right away
On Thu, Aug 15, 2019 at 8:40 AM Claude Pache wrote:
>
>
> Le 12 août 2019 à 22:00, Matthew Morgan a écrit :
>
>
Is there any way we can add function/operator equivalence to the language?
Perhaps some kind of 'operators' global object with symbol fields matching
operator string to functions/constraints?
--
Dammit babies, you've got to be kind.
On Thu, 15 Aug 2019 at 08:47, Andrea Gia
I wonder if there's any interest in adding another handy Array method as
joinWith could be:
```js
// proposal example
Array.prototype.joinWith = function (values) {
const {length} = this;
if (length < 2)
return this.join('');
const out = [this[0]];
const len = values.length;
for (let
Hello,
Back in ES5.1, there was a specification to evaluate programs
(https://www.ecma-international.org/ecma-262/5.1/index.html#sec-14).
What is the corresponding starting point in the current spec? Is
it
https://tc39.es/ecma262/#sec-scripts ?
Best,
Alan
signature.asc
Description: PGP sign
On 2019-08-15 10:53, Alan Schmitt
writes:
Back in ES5.1, there was a specification to evaluate programs
(https://www.ecma-international.org/ecma-262/5.1/index.html#sec-14).
What is the corresponding starting point in the current spec? Is
it
https://tc39.es/ecma262/#sec-scripts ?
Thanks to th
I would rather see Array.zip, it covers this use case.
On Thu, 15 Aug 2019, 10:50 Andrea Giammarchi,
wrote:
>
> I wonder if there's any interest in adding another handy Array method as
> joinWith could be:
>
> ```js
> // proposal example
> Array.prototype.joinWith = function (values) {
> const
1. the suggested name is just ... suggested, I don't have strong opinion
on it, it just `join` values through other values
2. what's `Array.zip` ? I've no idea
On Thu, Aug 15, 2019 at 12:53 PM Michał Wadas wrote:
> I would rather see Array.zip, it covers this use case.
>
> On Thu, 15 A
https://lodash.com/docs/#zip
https://docs.python.org/3/library/functions.html#zip
On Thu, 15 Aug 2019, 15:34 Andrea Giammarchi,
wrote:
>
>1. the suggested name is just ... suggested, I don't have strong
>opinion on it, it just `join` values through other values
>2. what's `Array.zip`
We could circumvent this by making `%%` analogous to `**`. That is, we could
provide a function form `Math.mod` as well as an infix operator `%%`.
On Thursday, August 15, 2019 9:46:57 AM CEST Andrea Giammarchi wrote:
> FWIW another disadvantage is that operators cannot be polyfilled, so it'll
> t
To me there's no risk, as MooTools, Prototype, and Scriptacolous are both
things of the past, and never implemented Math.mod ... so, with that
approach, custom transpiling functions are more dangerous, as somebody
might have implemented `%%` already for other purposes, and we break Babel
outcome ad
That;s not useful for template literals tags though
_.zip(['a', 'b', 'c'], [1, 2]);
[["a", 1], ["b", 2], ["c", undefined]]
it basically does nothing I've proposed ... any other name suggestion?
On Thu, Aug 15, 2019 at 3:40 PM Michał Wadas wrote:
> https://lodash.com/docs/#zip
> https://docs.py
An operator is far more concise than a function call, and is likely to
see greater use. It also aligns better with peoples' intuition on what
the "modulus" is, avoiding subtle bugs like in `isOdd = x => x % 2 ===
1` (example from
https://en.wikipedia.org/wiki/Modulo_operation#Common_pitfalls - try
Fair points, but since `**` has its `Math.pow` counter part, why wouldn't
`%%` have `Math.mod` as counterpart too? At least it looks like there's
room for both, if standardized, as the behavior and description would
likely be mostly the same (precedence a part)
On Thu, Aug 15, 2019 at 7:13 PM Isia
On 8/14/19 7:50 PM, Waldemar Horwat wrote:
> And I'm saying that's potentially problematic because it changes the meaning
> of existing programs that happen to use "mod" as a variable name. The above
> is one example that would turn a let statement into a mod expression. Here's
> another exam
"weave"? (I've likely missed the purpose of the method)
On Thu, 15 Aug 2019, 18:12 Andrea Giammarchi,
wrote:
> That;s not useful for template literals tags though
>
> _.zip(['a', 'b', 'c'], [1, 2]);
> [["a", 1], ["b", 2], ["c", undefined]]
>
> it basically does nothing I've proposed ... any othe
Thursday, August 15, 2019 2:47 AM, Andrea Giammarchi wrote:
> FWIW another disadvantage is that operators cannot be polyfilled, so it'll
> take forever for those not using transpilers to adopt these, while having a
> `Math,mod` would work right away
With such an approach there is risk of anoth
Static functions don't have the same risk as prototype functions;
`Math.mod` would make sense to add.
One suggestion, though, would be to try to add the API method first, and
look at usage for awhile before trying to add the syntax.
On Thu, Aug 15, 2019 at 10:12 AM Andrea Giammarchi <
andrea.giam
BTW, I just wrote up a more precise, formalized proposal over here:
https://github.com/isiahmeadows/proposal-divisor-dependent-modulo/,
and I'd be more than willing to work with a TC39 champion on it. I
personally prefer syntax (pretty strongly), but I'm not beholden to
it.
I do feel the semantics
There is a whole example that produces a string, like join does, using the
second argument iterable to fill the "junctions" ... which part is not
clear in the test case?
```js
console.log(['a', 'b', 'c', 'd'].joinWith([1, 2]));
// a1b2c1d
function tag2str(template, ...values) {
return template.
It should be possible to add a second optional argument to the `find` and
`findIndex` array methods, similarly to `indexOf`
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
isn't the second argument already reserved for the context?
```js
[1, 2, 3].findIndex(function (i) { return i == this; }, 2);
// 1
```
On Thu, Aug 15, 2019 at 11:51 PM Cyril Auburtin
wrote:
> It should be possible to add a second optional argument to the `find` and
> `findIndex` array methods,
I believe every array iteration method that takes a callback, except for
reduce and reduceRight, take an optional receiver as the last argument (the
`this` value), so they can't be meaningfully/ergonomically extended.
On Thu, Aug 15, 2019 at 3:00 PM Andrea Giammarchi <
andrea.giammar...@gmail.com>
For that, I'd rather see an `interleave` that just rotates through all
its arguments. It'd be basically sugar for `.zip().flat()`, but an
implementation could optimize the heck out of it. (In particular, they
could iterate through them one-by-one and only allocate once, not in
the hot loop, so it'd
23 matches
Mail list logo
