domenic at domenicdenicola.com (2013-07-19T15:39:54.605Z)
On Tue, Jul 16, 2013 at 3:45 PM, David Bruant <bruant.d at gmail.com> wrote: > I have been thinking and with for..of, I can't find a good reason to use > .forEach instead of for..of. > for..of does what you need here with generators too. I've been looking at this example and thinking the same thing. Additionally, I'm curious to know what this would've looked like without being a contrived example of mis-used yield, considering Array.prototype.forEach returns undefined and the callback returns undefined as well (regardless of whether or not user code specifies a return).
On Tue, Jul 16, 2013 at 3:45 PM, David Bruant <bruant.d at gmail.com> wrote: > Le 16/07/2013 19:54, Claus Reinke a écrit : > > // this doesn't work >> function* generator(){ >> [1,2,3].forEach( function(x){ yield x } ) >> } >> > I have been thinking and with for..of, I can't find a good reason to use > .forEach instead of for..of. > for..of does what you need here with generators too. I've been looking at this example and thinking the same thing. Additionally, I'm curious to know what this would've looked like without being a contrived example of mis-used yield, considering Array.prototype.forEach returns undefined and the callback returns undefined as well (regardless of whether or not user code specifies a return). Rick > > > This would make generators deep, violating the non-interleaving >>> assumptions >>> of intermediate callers on the call stack. This is why we accepted >>> generators only on condition that they be shallow. We knew at the time >>> that >>> this privileges built-in control structures over user defined ones. The >>> alternative would have been to omit generators completely. We agree that >>> shallow generators were worth it, despite this non-uniformity. >>> >> >> While I understand the compromise, and the wish to get in some form >> of generators anyway, the discrimination against user-defined control >> structures troubles me deeply. It introduces a new language construct >> that defies abstraction. It means that we can no longer use functional >> abstraction freely, but have to worry about interactions with generators. >> >> For the specific case of forEach et al >> > What do you mean by "et al"? I don't believe .map, .reduce or .filter are > any interesting to use alongside generators. > > Even if so, for..of can work too and is decently elegant (YMMV): > > function* g(){ > [1,2,3].map(x => {yield transform(x)}) > } > > becomes > > function* g(){ > for(x of [1,2,3]) yield transform(x); > } > > David > > ______________________________**_________________ > es-discuss mailing list > es-discuss at mozilla.org > https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130716/a15fce1f/attachment.html>