AP> В сообщении от Thursday 25 September 2008 22:01:21 Dmitry E. Oboukhov
AP> написал(а):
AP>>> Так намного лучше. Хотя вот в таком эскейпинге - \@ очень легко
AP>> ошибиться. Ну AP> и $@ или $_ читабельности не добавляют, а совместо с ; в
AP>> конце строки AP> становятся малочитаемыми.
AP>> так это вопрос выбора имен переменных
AP>> речь идет о том что читает код всеж таки специалист
AP> Специалист тоже человек и на конструкциях вида $#@ ошибиться немудрено
AP> каждому. Хм, а я правильно написал получение количества элементов? :-)
неправильно # - индекс последнего элемента
а количество элементов это или scalar(@ary) или в сравнениях (скалярном
контексте) scalar опустить можно
AP>> вот отвлечься от Perl, взять Makefile, там полно всяких $@, $<, $> итп
AP>> никто же не говорит что makefile масдай все пишут/используют
AP>> альтернатив в общем-то никто и не брался придумывать ;)
AP> Мэйкфайл это набор вызовов внешних утилит, это "сборочный шелл", а не язык
AP> программирования.
однако на нем вполне себе программы пишут и еще приличной сложности.
а чем шелл от языка программирования отличается?
AP>> а стандартные имена стандартных временных переменных это как бы
AP>> стандартное и соответственно претензии к нечитабельности идут только от
AP>> тех кто этим не пользуется.
AP> А зачем их так много?
ну не так уж и много, часто используемых десяток едва наберется
AP>>> На тикле я его в catch засуну на продакшене да еще в защищенный
AP>> интерпретатор AP> упакую. В тикле средства защиты динамического кода
AP>> предусмотрены. ну и в перле я его в eval завернул (что тоже что твой catch)
AP>> и в перле есть рестриктед перл-песочница
AP> Как я понимаю, перловый eval это не перехватчик ошибок, а передача кода на
AP> выполнение.
дык и перехватчик ошибок тоже.
AP> Когда-то пробовал в перле такой метод - быстро бросил, потому что
AP> вложенный эскейпинг жуткий просто становится. Скажем, если нужно написать
AP> код, кодорый будет выполнен и передан в код, где он еще раз будет выполнен, в
AP> перле это страшно смотрится.
а можно проще, без ескейпинга
eval {
обычный перловый код
};
просто в _конкретно данном случае_ проще было eval с кавычками позвать
:)
AP>>> Да все не нравится. Вот выдернуть кусок кода из контекста
AP>>>>> eval "foo_$$_[0](\$\$_[1])";
AP>>>>> foo_unknown($$_[1]) if $@;
AP>> выдернуть твой кусок из контекста с {}-ми \/-ми запятыми итп
AP> Прямой слэш я привык эскейпить, хотя это и не обязательно. {} можно заменить
AP> на "" - это пустая строка. Ну и чуть по-другому записать
AP> set replist {to: "" :CV: "" ( "" ) "" : "" , "" / "" -> "" $ "" [ "" ] ""}
AP> Так вот понятнее?
неа (честно, не флейма ради а именно честно) :)
AP>> так оно хуже регекспов тобой же приведенных выглядит
AP>> только что покороче чуток
AP>>
AP>> set replist [list to: {} :CV: {} ( { } ) { } : { } , { } \/ { } -> { } $ {}
AP>> \[ {} \] {}]
AP> Правило трансляции входных данных - выкидываем все незначащие символы
AP> разметки. Принципиально отличается от регекспов, которые в общей куче ищут
AP> полезные данные, что и делает их более тяжелыми для восприятия и более
AP> подверженными ошибкам.
регекспы можно писать в много строк, с коментариями итп
когда сложные они я так и пишу :)
AP> Хорошие комментарии не спасут плохой код, зато хороший код может не иметь
AP> комментариев.
хороших коментариев при плохом коде не встречал
хорошего неоткоментированного кода тоже не видал
--
. ''`. Dmitry E. Oboukhov
: :’ : unera@debian.org
`. `~’ GPGKey: 1024D / F8E26537 2006-11-21
`- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537
Attachment:
signature.asc
Description: Digital signature