Как стать автором
Поиск
Написать публикацию
Обновить

Комментарии 21

Не увидел никаких «продвинутых возможностей JavaScript-функций».
Увидел стандартные приёмы использования функций, в равной степени применимые в любом ЯП.
Ещё и с ошибками в коде (if(user.sex = 'man')), указывающими на то, что автор свой код даже не пытался запускать.
Всего голосов 19: ↑19 и ↓0+19
автор свой код даже не пытался запускать

Вообще-то мог даже и попытаться ;-): программа с ошибкой не вывалится, а если автор еще и тест сделал на пользователе мужского пола — то даже получил правильный результат.
PS Лично я по причине таких ошибок ещё с давних времен работы на C, когда компиляторы были не такими дотошными, как сейчас, всегда при проверке на равенство старался слева писать не переменную, а константу или выражение, чтобы ошибка компиляции была гарантирована — и даже в C#, где компилятор такую дичь не пропустит, так по привычке пишу.
Комментарий пока не оценивали0

Как и 99% других постов от ru_vds.

Всего голосов 7: ↑7 и ↓0+7

В общем вот тебе фунция чтобы ты мог вызвать функцию которая вызовет функцию. Но вызов функии чаще дороже выполнения простых операций на месте. Вот если бы в Javascript таки встроили модификатор "inline" как в C было бы не плохо.

Всего голосов 7: ↑0 и ↓7-7
Во-первых, модификатор «inline» в современном Си означает не то, что вы думаете:
Historically, the inline C++ keyword was originally an optimizer hint, but optimizers were given permission to ignore it and make their own decisions about inline substitution during code generation. Nowadays, compilers pretty much ignore the optimization aspect of the inline keyword. The only thing that remains of the inline keyword is the ability to have multiple definitions without violating ODR.

Во-вторых, JIT вполне может заинлайнить вызов, если решит, что это того стоит.

В-третьих, претензии по типу «в JS нет моей любимой фичи из Си, вот бы её добавили» — это примерно как «моим шуруповёртом неудобно заколачивать гвозди, вот бы ему приделали боёк как у молотка».
Всего голосов 8: ↑8 и ↓0+8

Для меня модификатор inline это признак который скажет и программисту и компилятору что тело функции должно быть встроено в место её вызова.


Это позволяет простым коротким операциям дать понятное имя и использовать его без накладных расходов на вызов функции.


По мне так такой модификатор гораздо понятнее чем макросы.

Всего голосов 4: ↑0 и ↓4-4
Как объяснено выше, компилятор Си сам решает, встраивать ли тело функции в место её вызова — не глядя на этот модификатор.
Всего голосов 3: ↑3 и ↓0+3
Ответ в общем дан. При этом компилятор может поглядеть, что функция используется 1 раз и встроить её независимо от размера. Опять же компилятор может вообще всегда встраивать функции с малым размером, с одним выражением и т.д., это зависит ещё от указанного уровня оптимизации. В C++ при работе с шаблонной магией, когда прям вот compile-time не получится использовать, где-нить к примеру на последнем этапе или работа с runtime инфой, то компилятор без указания inlne почти всегда функции встраивал. В общем да, inline не показатель сейчас, вообще. А так же в догонку, компилятор может и циклы развернуть и рекурсию в цикл превратить и т.д. И ничего для этого говорить ему не надо.
Всего голосов 1: ↑1 и ↓0+1
Учитывая, что подавляющее число проектов используют минификатор github.com/terser/terser,
то вполне можно использовать аннотацию /*@__INLINE__*/
Всего голосов 1: ↑1 и ↓0+1
Охренеть, это теперь продвинутые возможности. Видимо, шутка про рекурсию теперь не только про php-шников?
Давайте в следующий раз про оптимизацию хвостовой рекурсии? А, и ещё можно линзы описать в статье «Ультра-фичи js, для понимания которых нужно три докторских степени»
Всего голосов 2: ↑1 и ↓10

Это ruvds, у них статьи для пиара хостинга, не стоит воспринимать это всерьёз, другое дело что такие статьи всегда в топе из-за того что их плюсуют сотрудники

Всего голосов 2: ↑2 и ↓0+2
Бывает переводят и хорошие материалы. Но тут опять кликбейт с медиума про набор из популярных слов (Pure Function, Higher-Order Function, Function Caching, Lazy Function, Currying и Function Compose).
Всего голосов 3: ↑3 и ↓0+3
А что за шутка про рекурсию и пхпшника?
Всего голосов 7: ↑5 и ↓2+3

Я, наверное, недостаточно продвинутый, но вот такие "ленивые" функции должны превращать отладку в ад, нет? Ты думаешь, что функция делает что-то определенное, а она сама себя подменяет в зависимости от каких-то внешних условий… расскажите, это реально используется или просто "потому что могу"?

Всего голосов 6: ↑6 и ↓0+6

Я ни разу не встречал. Вместо этого к функциям явным образом приделывают мемоизацию. Этот способ решения проблемы подразумевает более простой и понятный код.

Всего голосов 1: ↑1 и ↓0+1

Ну так и синглтон поступает примерно так же. Конечно, это добавляет неочевидности, но не вижу почему вдруг отладка должна превращаться в ад. Отладка — это само по себе нелинейное понятие, при тщательной отладке заходите в тело каждой вызываемой функции и видите что происходит. Да и не заходя, нужно проверять возвращаемый результат (то есть нет никакого "я думал оно всегда возвращает a, а оно возвращает b").
Это не по ивентам (которые вызваны другими ивентами, которые вызваны другими ивентами) прыгать, вот уж где можно повеселиться.

Всего голосов 1: ↑1 и ↓0+1

С чего бы отладка в ад превращалась? В отладчике же всегда можно увидеть какая именно функция скрывается за конкретным именем в любой момент времени.

Комментарий пока не оценивали0
for (int i = 0; i < 1000; i++){

Мы точно про Javascript?
Всего голосов 5: ↑5 и ↓0+5
Переводчик вкладки попутал )
Комментарий пока не оценивали0
Нет, в оригинале вся та же муть.
Всего голосов 1: ↑1 и ↓0+1
Ну тогда к переводчику вопросов нет, только к заказчику )
Всего голосов 1: ↑1 и ↓0+1
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Ваш аккаунт

Разделы

Информация

Услуги

Техническая поддержка
© 2006–2024, Habr