Опять таки здесь, нет нормального наследования: для каждого нового объекта создается свой объект-прототип. В примере выше через верхний IIFE прототип создан один раз и доступ к нему создаваемые объекты имеют через замыкание.
О, да я не один такой! =)
Спасибо большое за решение и за ссылку! MDN я возможно уже перечитал: все чаще нахожу вдохновение в самой спецификации. Там еще столько интересного…
В примере с числами Фибоначчи. Если мы захотим перенести функцию в другую переменную, то есть:
let rf2 = rf;
rf = null;
В случае с декларированием функции (FunctionDeclaration), мы получим ошибку. Так как внутри функция будет вызывать себя по старому имени. Такая защита.
Ну а сам FunctionExpression полезен например при условном объявлении функции, так как такая функция создается в процессе выполнения выражения:
let fe;
if (cond) {
fe = function() { /* 1 */ };
} else {
fe = function() { /* 2 */ };
}
Да, в случае с замыканием нам потребуется вернуть объект-контейнер: вызываемая функция + геттер для получения количества обращений. Настоящий пример демонстрирует работу с функцией внутри NFE как с объектом. JavaScript позволяет решить простую задачу, избегая лишнего кода.
Повторюсь, что подобное обращение с функцией в поставляемом коде — недопустимо. Но для локальных задач сгодится на отлично.
Да, возможно ) Я сравнил это с self-XSS, потому что, подтверджая концепт, я просил своих коллег выполнить эти действия на их стороне в окне переводчика.
Отличная попытка ) но я боюсь мы не можем пренебречь сводимым к false результатами. Например, если вызов декорируемой функции используется в условии while или ожидается false для выхода из рекурсии. Опасная подмена 0 на 1, но спасибо за мысль!
К слову, когда мы принимали решения от соискателей, то часто звучали справедливые комментарии мол не думали что укорачивать надо так однострочно. Но при оценке решений мы обращали внимание именно на используемые языковые выражения и пропущенные подводные камни.
Да, в первой части статьи про чистую реализацию так и сделал. Это контрольная точка перед дальнейшей грязной доработкой, где уже за каждый символ приходится бороться: за тот же пробел перед in operator )
Я повторюсь, что если полагаться на toString, то можно и просто:
f=>(...a)=>f[a]=a in f?f[a]:f(...a);
Но по условию задачи в качестве аргумента может быть объект, и тогда тест 6 падает на [object Object]. В этом основная сложность: найти кратчайшую функцию сериализации или хэширования.
Про особенности JSON.stringify упомянул; циклические ссылки в контексте поставленной задачи кажутся особым кейсом — пренебрегаем.
Если полагаться на toString, то join произойдет у Array.prototype.toString, так как мы отошли от arguments в пользу массива и будет еще короче. Но накладывать такие требования на данные — это слишком. Каноничней тогда на полифилы hashCode и equals посмотреть.
Угу, я поэтому в своем примере использовал join строк вместо темплейта.
У вас явная предрасположенность к деструктуризации ) выглядит правда интереснее comma operator'а.
Я даже не подумал об этом! Круто )
Вот оно уже настоящее зло )
Спасибо большое за решение и за ссылку! MDN я возможно уже перечитал: все чаще нахожу вдохновение в самой спецификации. Там еще столько интересного…
В примере с числами Фибоначчи. Если мы захотим перенести функцию в другую переменную, то есть:
В случае с декларированием функции (FunctionDeclaration), мы получим ошибку. Так как внутри функция будет вызывать себя по старому имени. Такая защита.
Ну а сам FunctionExpression полезен например при условном объявлении функции, так как такая функция создается в процессе выполнения выражения:
Это уже другая тема )
Повторюсь, что подобное обращение с функцией в поставляемом коде — недопустимо. Но для локальных задач сгодится на отлично.
т.е. сохраняем 0 или любое другое сводимое к false и всегда проваливаемся во второй операнд ИЛИ.
Но по условию задачи в качестве аргумента может быть объект, и тогда тест 6 падает на [object Object]. В этом основная сложность: найти кратчайшую функцию сериализации или хэширования.
Если полагаться на toString, то join произойдет у Array.prototype.toString, так как мы отошли от arguments в пользу массива и будет еще короче. Но накладывать такие требования на данные — это слишком. Каноничней тогда на полифилы hashCode и equals посмотреть.