Комментарии 31
Статья готовилась для блога «Великий язык PERL!», но кармы пока маловато. Перенесу при первой возможности.
замечательно :) требую настойчиво продолжения!
в perl огромное количество фич, но юзается малая часть. так и с атрибутами.
автор подобрал удачные примеры, но вот лень (моя) подсказывает что лучше придерживаться привычных схем в которых отсутствует сабж :)
автор подобрал удачные примеры, но вот лень (моя) подсказывает что лучше придерживаться привычных схем в которых отсутствует сабж :)
Эдак можно реализовать декораторы, как я вижу. Мощно.
На сколько я понимаю это широко используется в перловом Catalyst-е
1
Я время от времени пытаюсь использовать редкие фичи, например фильтры, но натыкаюсь на случаи, когда они не работают или работают нетривиально. А работают программы у меня от Perl 5.6 до последних версий.
Реально атрбуты, как мне кажется, только способствуют запутыванию кода.
sub myMethod :Method($x) выглядит красиво, но не читается теми, кто атрибуты не использует Написать
sub abc {my $x = shift;}
несложно, зато нет никаких лишних зависимостей и всё понятно.
Реально атрбуты, как мне кажется, только способствуют запутыванию кода.
sub myMethod :Method($x) выглядит красиво, но не читается теми, кто атрибуты не использует Написать
sub abc {my $x = shift;}
несложно, зато нет никаких лишних зависимостей и всё понятно.
по поводу читабельности согласен. трудно предугадать кто будет поддерживать код. некоторые все еще пишут return undef; в своих творениях :)
И правильно делают, кстати.
а как же постулаты Perl Best Practices? O o
А кто их читает. Perl — язык для практиков. Главное — чтобы было удобно. И так умолчаний слишком много.
> А кто их читает
Вот и получается write-only
Вот и получается write-only
Два Perl-кодера иногда могут не понимать код друг друга… иногда бывает обидно, а что еще хуже препятсвует дальнейшей разработке.
В других языках проще с этим, так как они более менее стандартизированы. А на Perl тебе ничего не мешает свой язык написать, в котором уж никто ничего без тебя не поймет — обфускация )
Впрочем даже в C практиковались не очень хорошие практики, видел код
Комуто ведь было удобнее писать
В других языках проще с этим, так как они более менее стандартизированы. А на Perl тебе ничего не мешает свой язык написать, в котором уж никто ничего без тебя не поймет — обфускация )
Впрочем даже в C практиковались не очень хорошие практики, видел код
#define if if (
#define then ) {
#define else } else {
#define endif }
Комуто ведь было удобнее писать
if a then
b = ...;
else
b = ...;
endif
Для программиста одиночки — это лишние заморочки!
Их применение важно при работе в команде, это своего рода стандарт кодирования без которого командная работа просто превратится в хаос и все друг друга поубивают в спорах у кого лучше.
PBP рекомендует явные return-ы (section 9.11).
Что касается return undef, то это вполне правильная команда, если функция должна вернуть скаляр. Отличающаяся от просто return. Использование одной, когда должна быть использована другая — баг. Так что return-ы всякие нужны, return-ы всякие важны! :)
Что касается return undef, то это вполне правильная команда, если функция должна вернуть скаляр. Отличающаяся от просто return. Использование одной, когда должна быть использована другая — баг. Так что return-ы всякие нужны, return-ы всякие важны! :)
Ну для такой ерунды их использовать конечно не стоит. Я привел этот пример, т.к. он меня действительно удивил. Когда я посмотрел на реализацию этого модуля, у меня случился небольшой нервный срыв :)
А вот пример с memoize выглядит уже более здраво. Есть типичный декоратор, реализующий одинаковое для любой функции поведение, пусть даже тривиальное. Копипастить его ручками — только зря код плодить, а так получается достаточно наглядно. У меня через подобный паттерн работает гораздо более хитрая система, и пока что я счастлив, сравнивая ее с тем что было раньше — новое поведение прикручивается не за час с хреном, а за 5 минут.
Хотя я согласен, что такие трюки заслуживают документирования в первую очередь — хотя бы ввиду того, что не каждый знает про подобный синтаксис.
А вот пример с memoize выглядит уже более здраво. Есть типичный декоратор, реализующий одинаковое для любой функции поведение, пусть даже тривиальное. Копипастить его ручками — только зря код плодить, а так получается достаточно наглядно. У меня через подобный паттерн работает гораздо более хитрая система, и пока что я счастлив, сравнивая ее с тем что было раньше — новое поведение прикручивается не за час с хреном, а за 5 минут.
Хотя я согласен, что такие трюки заслуживают документирования в первую очередь — хотя бы ввиду того, что не каждый знает про подобный синтаксис.
Это всё заплаты для сокрытия того факта, что ООП модель перла очень простая, гибкая, но слабоконтролируемая. Мне кажется, что использование чего-то, выходящего за базовые возможности, сильно бьёт по надёжности программы. Даже кэширование memoize вызывает вопросы — а какие алгоритмы для удаления из кэша, где хранится результат…
Если Вы реализуете то же самое через вполне базовое обращение к внешней функции, вопросы останутся и придется точно так же эти алгоритмы искать в другом месте. А по поводу надежности — аргументируйте, пока утверждение ничем не подкреплено. Я планирую через некоторое время написать о том, как атрибуты помогли навести порядок в одном достаточно крупном проекте. Новый код работает гораздо стабильнее и прозрачнее старого. Это конечно больше говорит о проблемах в старом коде, я могу также сделать вывод что надежность из-за новой фичи не упала.
Аргумент простой — все нововведения ненадёжны в принципе. В любой области. Если есть хорошая тестовая база — то ошибки быстро находятся, если нет — медленно. В данном случае тестовая база крохотная.
Реализовать свой алгоритм кэширования для более сложной задачи, чем кэширования sin(x), всё равно придётся.
Если проект сложный, то, наверно, можно вложиться в такого рода технологии, но у меня есть подозрение, что сложный проект на перле в принципе невозможно реализовать — перл морально устарел, поддерживать проекты на нём трудно.
Реализовать свой алгоритм кэширования для более сложной задачи, чем кэширования sin(x), всё равно придётся.
Если проект сложный, то, наверно, можно вложиться в такого рода технологии, но у меня есть подозрение, что сложный проект на перле в принципе невозможно реализовать — перл морально устарел, поддерживать проекты на нём трудно.
На счет читабельности вопрос, как всегда, спорный. Как раз для прототипов синтаксис обычный (например, Javascript). Как и для тех кто работал с блоками кода и н
Большое спасибо за статью! Давненько ничего не было по перлу, а жаль. С интересом прочитаю продолжение.
Кусок из Attribute::Method:
my $dp = B::Deparse->new();
...
sub UNIVERSAL::Method : ATTR(RAWDATA) {
my ( $pkg, $sym, $ref, undef, $args ) = @_;
my $src = $dp->coderef2text($ref);
if ($args) {
$src =~ s/\{/sub{\nmy \$self = shift; my ($args) = \@_;\n/;
}
else {
$src =~ s/\{/sub{\nmy \$self = shift;\n/;
}
no warnings 'redefine';
*$sym = eval qq{ package $pkg; $src };
}
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Атрибуты: введение