Return value of forEach
Andrea Giammarchi
andrea.giammarchi at gmail.com
Fri Oct 16 19:38:32 UTC 2015
The "complete" version might look more like the following:
```js
function pipe(f) {
return Object.defineProperties(
function (x) {
f.apply(this, arguments);
return x;
},
{
length: Object.getOwnPropertyDescriptor(f, "length"),
name: Object.getOwnPropertyDescriptor(f, "name")
}
);
}
```
yet I find this more complicated than just a map and if it is about
immutable then map wins even more.
I don't see why this is a problem in October 2015, Array#forEach has been
like that since ever.
Let's move on or maybe discuss a new method?
Regards
On Fri, Oct 16, 2015 at 7:51 PM, Isiah Meadows <isiahmeadows at gmail.com>
wrote:
> What about a `tap` function similar to Bluebird's `tap` function for its
> promises?
>
> I frequently write a `pipe` function that deals with this common case
> (with arrays, but frequently promises and other monadic structures as well).
>
> ```js
> // Complete transparent wrapper
> function pipe(f) {
> function g(x) {
> f.apply(this, arguments)
> return x
> }
>
> return Object.defineProperty(g, "length",
> Object.getOwnPropertyDescriptor(f, "length"))
> }
>
> // My usual lazy version
> function pipe(f) {
> return function (x) {
> f.apply(this, arguments)
> return x
> }
> }
>
> // My super-lazy version
> const pipe = f => x => (f(x), x)
> ```
>
> On Fri, Oct 16, 2015, 12:52 Kris Kowal <kris.kowal at cixar.com> wrote:
>
>> forEach should return undefined. Array-like methods for iterators solve
>> the problem of building unnecessary memory pressure for intermediate maps.
>>
>> The return value of forEach is special. True, for arrays it is always
>> undefined. However, the forEach method on an iterator returned by a
>> generator function should be the return value of the generator. Consider
>> this range generator that returns the number of visited values.
>>
>> ```js
>> function *range(start, stop, step) {
>> for (var index = start; index < stop; stop += step) {
>> yield index;
>> }
>> return (stop - start) / step;
>> }
>> var iterator = range(0, 10, 1);
>> var iterations = iterator.forEach((x) => console.log(x));
>> console.log(iterations);
>> ```
>>
>> Kris Kowal
>>
>> On Fri, Oct 16, 2015 at 7:30 AM, Andrea Giammarchi <
>> andrea.giammarchi at gmail.com> wrote:
>>
>>> That's usually a made-up issue ... the example code is using two maps
>>> instead of computing the entire thing once in a composed function **and**
>>> it already creates multiple copies of the initial Array.
>>>
>>> Anyway, having `var log = DEBUG ? x => console.log(x) || x : x => x` in
>>> means you could do this:
>>>
>>> ```js
>>> const a = log([1, 2, 3]
>>> .map(square))
>>> .map(plus1)
>>> .reduce(add);
>>> ```
>>>
>>> but again, we are using multiple maps and a reduce so if we want to be
>>> realistic, and it's for debugging purpose only, I think using map would be
>>> just fine.
>>>
>>> Regards
>>>
>>>
>>> On Fri, Oct 16, 2015 at 3:17 PM, Eric Devine <devineej at gmail.com> wrote:
>>>
>>>> Array#map does the non-trivial operation of copying the entire array.
>>>> In the example for loging to the console, this behavior is unintended.
>>>> Perhaps an underscore-like tap method should be considered to be added to
>>>> the Array prototype for these cases.
>>>>
>>>>
>>>> On Fri, Oct 16, 2015 at 9:32 AM, Andrea Giammarchi <
>>>> andrea.giammarchi at gmail.com> wrote:
>>>>
>>>>> Like I've written before, if you need to return an array you can use
>>>>> map instead of forEach
>>>>>
>>>>> `arr.map(x => console.log(x) || x)`
>>>>>
>>>>> forEach has been like this since ever so while you wonder what kind of
>>>>> code would look like based on the fact forEach doesn't return anything, I
>>>>> actually wonder how come there are still people expecting forEach to return
>>>>> something.
>>>>>
>>>>> So, it would be a breaking change and actually it's not needed since
>>>>> you have map.
>>>>>
>>>>> If the new Array, and for debugging purpose, is not desired, use `var
>>>>> log = DEBUG ? x => console.log(x) || x : x => x` and abuse it as much as
>>>>> you like.
>>>>>
>>>>> Would any of this work?
>>>>>
>>>>> Regards
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Oct 16, 2015 at 2:23 PM, Niloy Mondal <
>>>>> niloy.mondal84 at gmail.com> wrote:
>>>>>
>>>>>> > That'd be a compatibility break.
>>>>>>
>>>>>> Ugh... you mean people actually depend on `forEach` returning
>>>>>> `undefined` (which it always does) to do further task?
>>>>>>
>>>>>> I wonder what that kinda code would look like >.<
>>>>>>
>>>>>> On Fri, Oct 16, 2015 at 6:08 PM, Frankie Bagnardi <
>>>>>> f.bagnardi at gmail.com> wrote:
>>>>>>
>>>>>>> That'd be a compatibility break.
>>>>>>>
>>>>>>> If we end up getting :: though:
>>>>>>>
>>>>>>> ```js
>>>>>>> function logEach(){
>>>>>>> this.forEach((x) => console.log(x));
>>>>>>> return this;
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> const a = [1, 2, 3]
>>>>>>> .map(square)
>>>>>>> ::logEach()
>>>>>>> .map(plus1)
>>>>>>> .reduce(add);
>>>>>>> ```
>>>>>>>
>>>>>>> You could make that a global variable so you can sprinkle it around
>>>>>>> your code in development.
>>>>>>>
>>>>>>> Having some developer tools in the language would be nice though. I
>>>>>>> don't even think console.log is in the spec. A global like Debug.logThis
>>>>>>> for example would be a more general ::-able.
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Oct 16, 2015 at 5:32 AM, Andrea Giammarchi <
>>>>>>> andrea.giammarchi at gmail.com> wrote:
>>>>>>>
>>>>>>>> ```js
>>>>>>>> const a = [1, 2, 3]
>>>>>>>> .map(square)
>>>>>>>> .map(x => console.log(x) || x )
>>>>>>>> .map(plus1)
>>>>>>>> .reduce(add);
>>>>>>>> ```
>>>>>>>>
>>>>>>>> Regards
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Oct 16, 2015 at 10:13 AM, Niloy Mondal <
>>>>>>>> niloy.mondal84 at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Currently, `Array.prototype.forEach` returns `undefined`. It would
>>>>>>>>> be more
>>>>>>>>> useful if it returns the array itself.
>>>>>>>>>
>>>>>>>>> Say I have written some code like this...
>>>>>>>>>
>>>>>>>>> ```js
>>>>>>>>> const a = [1, 2, 3]
>>>>>>>>> .map(square)
>>>>>>>>> .map(plus1)
>>>>>>>>> .reduce(add);
>>>>>>>>> ```
>>>>>>>>>
>>>>>>>>> For some reason, I am not getting the expected output. For
>>>>>>>>> debugging, I would
>>>>>>>>> like the print the values after each step. My first initial
>>>>>>>>> reaction is to
>>>>>>>>> put a `forEach` step in between and print the values like so...
>>>>>>>>>
>>>>>>>>> ```js
>>>>>>>>> const a = [1, 2, 3]
>>>>>>>>> .map(square)
>>>>>>>>> .forEach(x => console.log(x))
>>>>>>>>> .map(plus1)
>>>>>>>>> .reduce(add);
>>>>>>>>> ```
>>>>>>>>>
>>>>>>>>> Unfortunately, this does not work as `forEach` returns
>>>>>>>>> `undefined`. I now have
>>>>>>>>> to comment out all the code below it. Having the _plug and play_
>>>>>>>>> behaviour for
>>>>>>>>> `forEach` would be very convenient.
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> es-discuss mailing list
>>>>>>>>> es-discuss at mozilla.org
>>>>>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> es-discuss mailing list
>>>>>>>> es-discuss at mozilla.org
>>>>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> es-discuss mailing list
>>>>> es-discuss at mozilla.org
>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20151016/6bf14dd3/attachment-0001.html>
More information about the es-discuss
mailing list