Почему фильтры источника Perl плохо и когда это в порядке для использования их?
Это - только структура с двумя переменными под капотом.
мне на самом деле не нравится использовать станд.:: пара для функциональных возвратов. Читатель кода должен был бы знать то, что .first и каков .second.
компромисс, который я использую иногда, состоит в том, чтобы сразу создавать постоянные ссылки на .first и .second при именовании ссылок ясно.
6 ответов
Только perl может анализировать Perl (см. этот пример ):
@result = (dothis $foo, $bar);
# Which of the following is it equivalent to?
@result = (dothis($foo), $bar);
@result = dothis($foo, $bar);
Такая двусмысленность очень затрудняет написание исходных фильтров, которые всегда добиться успеха и поступать правильно. Когда что-то идет не так, отладка становится неудобной.
После нескольких сбоев и прожигов я разработал суеверный подход: никогда не пытаться писать другой исходный фильтр.
Иногда я использую Smart :: Comments для отладки. Когда я это делаю, я загружаю модуль в командную строку:
$ perl -MSmart::Comments test.pl
, чтобы избежать любой возможности, что он может остаться включенным в производственном коде.
См. Также: Perl не может быть проанализирован: формальное доказательство
]Почему исходные фильтры плохие:
- Только perl не может анализировать Perl. (Исходные фильтры хрупкие.)
- Когда исходный фильтр выходит из строя, может случиться что угодно. (Они могут вносить незаметные ошибки, которые очень трудно найти.)
- Фильтры исходного кода могут нарушить работу инструментов, работающих с исходным кодом. (PPI, рефакторинг, статический анализ и т. Д.)
- Фильтры источников исключают друг друга. (Вы не можете использовать более одного за раз - если только вы не психотик.)
Когда они в порядке:
- Вы экспериментируете.
- Вы пишете одноразовый код.
- Вас зовут Дамиан, и вам должно быть разрешено программировать на латыни.
- Вы программируете на Perl 6.
Мне не нравятся исходные фильтры, потому что вы не можете сказать, что будет делать код, просто прочитав его. Кроме того, вещи, которые выглядят как неисполняемые, например комментарии, могут волшебным образом стать исполняемыми с фильтром. Вы (или, что более вероятно, ваши коллеги) можете удалить то, что считаете неважным, и сломать что-то.
Сказав это, если вы реализуете свой собственный маленький язык, который хотите превратить в Perl, фильтры исходного кода могут быть правильными орудие труда. Однако не называйте это Perl. :)
Стоит упомянуть что ключевые слова Devel :: Declare (и, начиная с Perl 5.11.2, подключаемые ключевые слова) не являются фильтрами исходного кода и не противоречат проблеме «только Perl может анализировать Perl». Это потому, что они запускаются самим парсером perl, они берут то, что им нужно, из ввода, а затем возвращают управление тому же самому парсеру.
Например, когда вы объявляете метод в MooseX :: Declare следующим образом:
method frob ($bubble, $bobble does coerce) {
... # complicated code
}
Слово «метод» вызывает синтаксический анализатор ключевых слов метода, который использует свою собственную грамматику для получения имени метода и анализа сигнатуры метода (которая не Perl, но это не обязательно - просто нужно четко определить). Затем он оставляет perl для синтаксического анализа тела метода как тела подпрограммы. Все, что где-либо в вашем коде, что не между словом «метод» и концом сигнатуры метода, вообще не просматривается парсером метода, поэтому он не может сломать ваш код, нет как бы сложно ни было.
который использует собственную грамматику для получения имени метода и анализа сигнатуры метода (это не Perl, но это не обязательно - просто нужно четко определить). Затем он оставляет perl для анализа тела метода как тела подпрограммы. Все, что где-либо в вашем коде, что не между словом «метод» и концом сигнатуры метода, вообще не просматривается парсером метода, поэтому он не может сломать ваш код, нет как бы сложно ни было. который использует собственную грамматику для получения имени метода и анализа сигнатуры метода (это не Perl, но это не обязательно - просто нужно четко определить). Затем он оставляет perl для анализа тела метода как тела подпрограммы. Все, что где-либо в вашем коде, что не между словом «метод» и концом сигнатуры метода, вообще не просматривается парсером метода, поэтому он не может сломать ваш код, нет как бы сложно ни было.Теоретически исходный фильтр не более опасен, чем любой другой модуль, так как вы можете легко написать модуль, который переопределяет встроенные или другие конструкции «неожиданным» образом. Однако на практике довольно сложно написать фильтр источника таким образом, чтобы можно было доказать, что он не сделает ошибки. Я пробовал свои силы в написании исходного фильтра, реализующего операторы подачи perl6 в perl5 ( Perl6 :: Feeds на cpan). Вы можете взглянуть на регулярные выражения, чтобы увидеть акробатические трюки, необходимые для простого определения границ области действия выражения. Хотя фильтр работает и предоставляет тестовую площадку для экспериментов с фидами, я бы не стал использовать его в производственной среде без еще многих часов тестирования.
Filter :: Simple, безусловно, пригодится, если будет иметь дело с ' кровавые детали синтаксического анализа цитируемых конструкций », поэтому я бы с осторожностью относился к любому исходному фильтру, который не начинается там.
В целом, это действительно зависит от используемого вами фильтра и от того, насколько широкой области он пытается сопоставить против. Если это что-то простое, например макрос ac, то это "вероятно" нормально, но если это что-то сложное, то это вызов для суждения. Мне лично не терпится поиграть с макросистемой perl6. Наконец, у lisp ничего не будет на perl: -)
Лично мне не терпится поиграть с макросистемой perl6. Наконец, у lisp ничего не будет на perl: -) Лично мне не терпится поиграть с макросистемой perl6. Наконец, у lisp ничего не будет на perl: -)Проблема, которую я вижу, - это та же проблема, с которой вы сталкиваетесь с любым макросом C / C ++, более сложным, чем определение константы: это ухудшает вашу способность понимать, что делает код, глядя на него, потому что вы не смотрите на код, который действительно выполняется.