miss_dead, речь про хеш-таблицы (ассоциативные массивы, если угодно). В js объект — это хеш-таблица. Есть объект Map в ES6, но почему-то автор решил использовать чистые объекты.
Преимущество в скорости доступа O(1), да и в удобстве тоже.
Массив предполагает работу через индексы или через итерирование, а это уже O(n).
А если вы будете работать с массивом как с хеш-таблицей, это будет выглядеть странно.
Все просто. Ваш пост очень похож на крик души. Вы не рассказали как на jsf создавать сайты, не показали, как это быстро, не показали ни одного примера успешной компании, которая использует jsf и главное Будет использовать его в новых проектах. Вместо этого ваш текст содержал некую насмешку и удивление тем, что кто-то считает grails живее jsf.
Думаю, большинство заходящих в топик ожидали увидеть более ценную информацию. Увидеть сравнение с другими технологиями или на худой конец информацию о том, как он развивается, что нового планируется в версии 2.3.
Вас обидели тем, что технология, на которую вы потратили полжизни теперь никому не нужна? Вы хотите поговорить об этом? Хабра — это не то место, куда вам нужно идти!
Если сильно нужно, в java есть project lombok, который на препроцессоре аннотаций автоматом создаст вам геттеры. Кода меньше, немного аккуратнее выглядит, но играть с магией — это всегда опасно.
Есть люди, у которых нету личной жизни, которые способны уделить время учебе, саморазвитию и работе по 10-12 часов в сутки. В универе без проблем можно попробовать 4 языка программирования сдавая лабораторные работы. На практике уже придется прыгать между вакансиями. А в свободное от работы время поработать над собственным проектом.
Единственный destination, который укладывается в понятие pure function — это возврат результата. Но в этом случае сломается весь концепт сравнения.
Самый простой пример паттерна «стратегия» в js называют callback.
Pure function для этого не обязателен, но в целом возможен — Array.map(), Array.reduce().
> Попробуем сделать это чистыми функциями:
> const logToDOM = (lvl,count,msg,node) => (node.innerHTML += `<div class="${lvl}">${count++}: ${msg}</div>`) && count;
Подождите, вы же сказали про Чистые функции и сами дали определение «без побочного эффекта».
При этом в примере у вас функция, которая имеет побочный эффект – изменяет состояние ноды.
Из этого топика я понял, что Гугл умеет гугловый AngularJS (прям удивительно!), Яндекс не умеет js, а у вас есть сайт, который вы пиарите без «я пиарюсь».
Как жуткое хитросплетение синхронных и асинхронных функций.
Как асинхронные функции, которые будут отдаваться наружу как результат выполнения
… и await await func() как следствие.
Как асинхронные функции в качестве параметров для тех же промисов или еще чего-то.
— проблема все та же = незнание как написать хорошо, порождает hell.
> async await впервые появился в c# в 2012 году и за 4 года не заработал себе плохой репутации.
Я могу ошибаться, но проблем с этим подходом не на много меньше, чем с обычным многопоточным программированием, просто эти проблемы сделали неявными.
Все те же await await func() и манипуляции с контекстом.
Да эти все «минные тропы» уже через месяц проходятся довольно просто, но не стоит забывать, что месяц — это у хорошего специалиста, который уже познал горя с многопоточностью.
Да и в C# вам множество тулов поможет и подскажет где вы не правы. В то время, как в ES это можно будет узнать только в рантайме и порою даже только на продакшене.
ps: я за развитие языка, но я против добавления Сахара ради сахара.
Цель благородная, но я к тому, что завтра появится async/await hell и быть беде. Если Promise API можно просто выкинуть и забыть (заменить на что-то новое), то async/await из спецификации уже не выкинешь.
Мой поинт о том, что не стоит вносить на уровень языка фичи главная цель которых сделать код красивее.
Понимаю, что сейчас будут дико минусовать карму, но: Зачем?((
1. Зачем вводить функционал до того, как он появится в стандарте (это еще draft на es2017)?
2. Зачем вводить async/await на уровне языка, учитывая, что это всего лишь сахар для промисов?
вот завтра окажется, что «async/await» — это плохо, а поддерживать эту фичу придется до конца жизни ES.
> так как в общем-то indexOf и includes по логике должны иметь одну и ту же вычислительную сложность.
Сложность у них разная будет, как ни крути. Вы же сами выше писали, что indexOf не правильно работает с NaN.
Для исправления этого огреха с NaN необходимо проверять каждый элемент массива на isNaN, при этом нужно будет проверить еще и тип элемента, т.к. isNaN('a') == true.
В то время когда Array.indexOf будет сравнивать по ссылке, а в некоторых случаях еще и по значению.
Обычно сообщество подхватывает каждый новый велосипед от фейсбука или гугла или еще от кого-то известного и сразу пытается затянуть в продакшн. Сразу появляется сотни статей на тему какой классный велосипед. И обычно мало кто думает «зачем еще один?», а вот конкретно в этом случае этот вопрос появился.
По-моему, когда в умах первая мысль «зачем еще один?», а не «вау! нужно перевести на новую технологию!» — это признак взросления.
Преимущество в скорости доступа O(1), да и в удобстве тоже.
Массив предполагает работу через индексы или через итерирование, а это уже O(n).
А если вы будете работать с массивом как с хеш-таблицей, это будет выглядеть странно.
Думаю, большинство заходящих в топик ожидали увидеть более ценную информацию. Увидеть сравнение с другими технологиями или на худой конец информацию о том, как он развивается, что нового планируется в версии 2.3.
Самый простой пример паттерна «стратегия» в js называют callback.
Pure function для этого не обязателен, но в целом возможен — Array.map(), Array.reduce().
> const logToDOM = (lvl,count,msg,node) => (node.innerHTML += `<div class="${lvl}">${count++}: ${msg}</div>`) && count;
Подождите, вы же сказали про Чистые функции и сами дали определение «без побочного эффекта».
При этом в примере у вас функция, которая имеет побочный эффект – изменяет состояние ноды.
Как жуткое хитросплетение синхронных и асинхронных функций.
Как асинхронные функции, которые будут отдаваться наружу как результат выполнения
… и await await func() как следствие.
Как асинхронные функции в качестве параметров для тех же промисов или еще чего-то.
— проблема все та же = незнание как написать хорошо, порождает hell.
> async await впервые появился в c# в 2012 году и за 4 года не заработал себе плохой репутации.
Я могу ошибаться, но проблем с этим подходом не на много меньше, чем с обычным многопоточным программированием, просто эти проблемы сделали неявными.
Все те же await await func() и манипуляции с контекстом.
Да эти все «минные тропы» уже через месяц проходятся довольно просто, но не стоит забывать, что месяц — это у хорошего специалиста, который уже познал горя с многопоточностью.
Да и в C# вам множество тулов поможет и подскажет где вы не правы. В то время, как в ES это можно будет узнать только в рантайме и порою даже только на продакшене.
ps: я за развитие языка, но я против добавления Сахара ради сахара.
Мой поинт о том, что не стоит вносить на уровень языка фичи главная цель которых сделать код красивее.
1. Зачем вводить функционал до того, как он появится в стандарте (это еще draft на es2017)?
2. Зачем вводить async/await на уровне языка, учитывая, что это всего лишь сахар для промисов?
вот завтра окажется, что «async/await» — это плохо, а поддерживать эту фичу придется до конца жизни ES.
Слава Богу, наконец-то кто-то написал просто про новые фичи в ES2015.
На счет строк — это оффтоп.
Сложность у них разная будет, как ни крути. Вы же сами выше писали, что indexOf не правильно работает с NaN.
Для исправления этого огреха с NaN необходимо проверять каждый элемент массива на isNaN, при этом нужно будет проверить еще и тип элемента, т.к. isNaN('a') == true.
В то время когда Array.indexOf будет сравнивать по ссылке, а в некоторых случаях еще и по значению.
По-моему, когда в умах первая мысль «зачем еще один?», а не «вау! нужно перевести на новую технологию!» — это признак взросления.