Разобравшись с инфой по ссылке не совсем понял какой профит принесет такой код относительно моего в том случае если декоратор поставить на рекурсивную функцию.
fact(N) when is_integer(N) andalso N>=1 ->
fact(N,1).
?MEMOIZE. % now decorator is here
fact(1,Acc) -> Acc;
fact(N,Acc) -> fact(N-1,Acc*N).
Это уже интереснее: могут выпилить, но могут таки и оставить, слегка улучшив :)
Не знаю как к этому относиться: с одно стороны не хочется чтобы Erlang потерял свою лаконичность из-за введения новых фич; с другой-же, складывается ощущение, что в нем чего-то таки не хватает. Какой-то мелочи, которая сделала бы его идеальным, по крайне мере для меня.
Но с тем что record не самое лучшее решение (особенно, из-за того что его структура теряется в runtime, что особенно критично когда State хранится в record и при добавлении нового поля при hot code reload все летит к чертям ) и его надо чем-то заменить, я полностью согласен.
Речь не о скорости выполнения, а о потребляемой памяти.
Вот набросал простой код для теста (у меня Erlang 15B01). Он съедает всю доступную память, т.к. не используется хвостовая рекурсия:
В пункте 5.9 в первом случае применяется не хвостовая рекурсия. При каждом входе в loop() в стек вызовов добавляется адрес возврата (для того чтобы при завершении выполнить io:format). Т.к, теоретически, сервер должен выполняться длительное время, то стек может переполниться. При использовании хвостовой рекурсии такого не происходит.
В данный момент использую Emacs с большим количеством плагинов. Благодаря ему, получилось много чего автоматизировать в процессе разработки. Я еще я пробовал ErlIDE (eclipse) и sublime text 2, но они не удовлетворяют моим потребностям.
Я, кстати, реализовывал loginRequired декоратор, когда писал проект под Cowboy.
Но смысл статьи просто продемонстрировать декораторы, а пример — первое что пришло в голову.
Вообще в своем коде я декораторы применяю только для отладки участков кода, а в production они и вовсе отключены.
Erlando наше все :)
+proplist нельзя match-ить
Не знаю как к этому относиться: с одно стороны не хочется чтобы Erlang потерял свою лаконичность из-за введения новых фич; с другой-же, складывается ощущение, что в нем чего-то таки не хватает. Какой-то мелочи, которая сделала бы его идеальным, по крайне мере для меня.
Но с тем что record не самое лучшее решение (особенно, из-за того что его структура теряется в runtime, что особенно критично когда State хранится в record и при добавлении нового поля при hot code reload все летит к чертям ) и его надо чем-то заменить, я полностью согласен.
tuple fun это как-то так:
Вот набросал простой код для теста (у меня Erlang 15B01). Он съедает всю доступную память, т.к. не используется хвостовая рекурсия:
Тест вызывался так:
без io:format все отлично работает.