Comments 32
Здесь мы просто извлекли анонимную встроенную стрелочную функцию, определённую до этого, и превратили в отдельную именованную.
Это бред. Не выдумывайте свои определения
extract the anonymous in-line arrow function we defined above and turn it into a separate named function
Вопрос на засыпку — а как перевести «inline» на русский язык?
Некоторое не переводится, например "инлайн стили" уже устоялись, было бы странно переводить как "встроенные стили". Если в контексте статьи и конкретной фарзы, то перевод слова инлайн избыточен, поэтому достаточно было написать "стрелочаня функция".
на мой вкус редюс лучше подходит для преобразования массивов в объект
var dict = ['Cat', 'Dog', 'Birg'].reduce((result, an, id) => { result[an] = id; return result;});
Не забывайте, что метод filter наверняка будет работать чуть медленнее, чем цикл for, пока браузеры и JS-движки не будут оптимизированы под новые методы работы с массивами.
Парой абзацев ниже
Не бойтесь начать использовать фильтрацию. В ES5 эта функциональность нативна и поддерживается почти везде.
АААААА, как быть то? Получается, не бояться использовать чтобы тормозило?
А разве в основе filter/map/reduce не лежат простые циклы?
Не совсем понятно в чем суть оптимизации если результат все равно будет O(n). Разве сейчас это уже не нативные методы? Во всяком случае в chrome Array.prototype.filter очень похож на нативный.
Мне кажется это уже попахивает фанатизмом, конечно O(n) бывает разным, на разных поколениях машин. Давайте теперь не будем пользоваться умножением и делением, особенно внутри циклов, ведь это очень накладно. Если вы пишете компилятор C++ на JavaScript, то наверное вы что то делаете не так, а для повседневного использования, отрисовки списков или обработки асинхронных сообщений на стороне сервера вам должно за глаза хватить всех операций стоимостью O(n). Про корень зла не забыли?
Неужели в счете и отрисовке вы используете filter/map/reduce? Хотя мы уходим немного в сторону. Вот смотрите кусочек Linq#Where кода аналога filter под Mono:
static IEnumerable<TSource> CreateWhereIterator<TSource> (IEnumerable<TSource> source, Func<TSource, bool> predicate)
{
foreach (TSource element in source)
if (predicate (element))
yield return element;
}Там есть еще один такой же для массивов с циклом for. Filter версия должна быть очень схожа. Я не вижу разницы буть то написано даже на js или прямиком на c++. Метод прост как трусы за рубль двадцать. Вот что здесь оптимизировать, какие тут мега сложные проверки, которые нужно устранить?
В моно у вас компилятор перед выполнением все проверки сделает и выдаст вам идеальный машинный код, а в жс это все будет делать JIT ему прийдется многое угадывать и про ваш элемент и про ваш предикат. А если код который будет выполняться в компиляторе написан на смеси жс и с++ (да v8, это как раз компилятор с++ на жс и с++) то у вас будет теряться время на переход, так что не все так просто.
var a = ['a']
a.filter(i => { a.push('b'); return Math.random() > 0.5 })
Трусы за рубль двадцать будут несколько проще таки. И оптимизировать тут есть что.
const threeLetterAnimals = animals
.filter(exactlyThree)
.map(capitalize)
.reduce(studlyCaps);
сначала создаст отфильтрованный массив, потом ещё дополнительно два раза по нему пробежится?
Если так, то выглядит, конечно, красиво, но как то не сильно производительно.
Ясное дело, это пример, но всё равно выглядит как то не очень.
Добро пожаловать в жестокий мир. Не совсем понятно почему это не сильно производительно, сложность тут линейная O(n). Но к счастью если вас заботит раздутие конечного автомата вы всегда можете использовать трансдьюсeры
сложность тут линейная O(n)Это не отменяет факта, что по массиву пробежимся два раза.
За трансдьюсеры спасибо, не знал про такое. Тогда да, можно красоту наводить.
for(const el of arr) {f(el); g(el);}
и
for(const el of arr) f(el);
for(const el of arr) g(el);
не значительна
Но всё равно мне не нравится такое увеличение на пустом месте ради красоты. Наверное, опыт программирования микроконтроллеров даёт такие страшные побочные эффекты ))).
Как правило, если проект большой, лучше писать красивее и понятнее, а уже потом думать о скорости. Часто узкие места появляются совсем не там где их ждешь.
Фильтрация и создание цепочек в функциональном JavaScript