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

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

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

Во-первых, модификатор «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 нет моей любимой фичи из Си, вот бы её добавили» — это примерно как «моим шуруповёртом неудобно заколачивать гвозди, вот бы ему приделали боёк как у молотка».

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


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


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

Как объяснено выше, компилятор Си сам решает, встраивать ли тело функции в место её вызова — не глядя на этот модификатор.
Ответ в общем дан. При этом компилятор может поглядеть, что функция используется 1 раз и встроить её независимо от размера. Опять же компилятор может вообще всегда встраивать функции с малым размером, с одним выражением и т.д., это зависит ещё от указанного уровня оптимизации. В C++ при работе с шаблонной магией, когда прям вот compile-time не получится использовать, где-нить к примеру на последнем этапе или работа с runtime инфой, то компилятор без указания inlne почти всегда функции встраивал. В общем да, inline не показатель сейчас, вообще. А так же в догонку, компилятор может и циклы развернуть и рекурсию в цикл превратить и т.д. И ничего для этого говорить ему не надо.
Охренеть, это теперь продвинутые возможности. Видимо, шутка про рекурсию теперь не только про php-шников?
Давайте в следующий раз про оптимизацию хвостовой рекурсии? А, и ещё можно линзы описать в статье «Ультра-фичи js, для понимания которых нужно три докторских степени»

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

Бывает переводят и хорошие материалы. Но тут опять кликбейт с медиума про набор из популярных слов (Pure Function, Higher-Order Function, Function Caching, Lazy Function, Currying и Function Compose).

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

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

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

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

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.