It's not wasteful if, as I said, they are iterator-consuming functions. I'm not sure why you think mutating a closed-over variable is better or more efficient code. Email me off list and I'll explain, or just look up the Python 3 map and filter (or Python 2 itertools equivalents).
On Tuesday, April 7, 2015, Andrea Giammarchi <[email protected]> wrote: > not sure if off topic but > > * you need a with statement to use lodash like that > * ... the following ... > > ``` > let found = first(filter( > map(files, _ => path.resolve(base, _)), > fs.existsSync > )); > ``` > > is a very wasteful pattern ... have you ever heard of `some` ? > > ``` > let found; > some(files, _ => fs.existsSync(found = path.resolve(base, _)) || (found = > '') || false); > ``` > > It could bring few alchemies in ;-) > > > On Tue, Apr 7, 2015 at 9:14 PM, Alexander Jones <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: > >> You need lazy sequences aka iterators. They give you the rather optimal: >> >> let found = first(filter( >> map(files, _ => path.resolve(base, _)), >> fs.existsSync >> )); >> >> Libs like lodash and lazy.js provide the bits you need, which are >> actually fairly trivial to build on top of nice new ES6 iterators if you >> want. >> >> Alex >> >> >> On Tuesday, April 7, 2015, Martin Heidegger <[email protected] >> <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: >> >>> I am probably very late to the game but I just read about harmonies >>> “Array.prototype.find” and found that it might be worth considering a >>> change in way it works. Its not a drastic change but it would break the >>> compatibility to the current setup. I understand that the chances for this >>> going through will be slim but since I would like to give it a shot anyways: >>> >>> Currently the API uses a callback function that has to return a boolean >>> to identify the item that has been found. This is good because find & >>> findIndex can use the same methods but it also has a drawback. >>> >>> Problem: Say you have a list of items that need to be processed before >>> you know if you “found” the item. Then you will need to process the last >>> item again since there is no way to “keep” the result (A) of the find >>> method or you preprocess all items using map (B) that will require to >>> process all the items even if the first one already matches. >>> >>> Example: >>> >>> (BASE) >>> var files = [“main.md”, “backup.md”] >>> var base = “/my/root" >>> >>> (A) >>> // Specifies `path.resolve` on two places >>> var found = files.find(function (file) { >>> return fs.existsSync(path.resolve(base, file)) >>> })) >>> if (found) >>> found = path.resolve(base, file) >>> >>> (B) >>> // Runs `path.resolve` for all items >>> var found = files.map(function (file) { >>> return path.resolve(base, file) >>> }).find(fs.existsSync) >>> >>> Proposal (C): I think it might be interesting to have a change of the >>> signature so that the return value is not true/false but the value that >>> actually will be returned (not undefined): >>> >>> (C) >>> var found = files.find(function (file) { >>> file = path.resolve(base, file) >>> if(fs.existsSync(file)) >>> return file >>> }); >>> >>> This way the operations would be minimised, it is still few to write and >>> it would make life a bit easier. >>> >>> yours >>> Martin Heidegger >>> _______________________________________________ >>> es-discuss mailing list >>> [email protected] >>> https://mail.mozilla.org/listinfo/es-discuss >>> >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> <javascript:_e(%7B%7D,'cvml','[email protected]');> >> https://mail.mozilla.org/listinfo/es-discuss >> >> >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
