Dmitry E. Oboukhov пишет:
AP> Так намного лучше. Хотя вот в таком эскейпинге - \@ очень легко ошибиться.
Ну
AP> и $@ или $_ читабельности не добавляют, а совместо с ; в конце строки
AP> становятся малочитаемыми.
так это вопрос выбора имен переменных
речь идет о том что читает код всеж таки специалист
вот отвлечься от Perl, взять Makefile, там полно всяких $@, $<, $> итп
никто же не говорит что makefile масдай все пишут/используют
альтернатив в общем-то никто и не брался придумывать ;)
Альтернатив make много, а вот как у этих альтернатив обстоят дела с именами
переменных
утверждать не берусь.
AP> На тикле я его в catch засуну на продакшене да еще в защищенный
интерпретатор
AP> упакую. В тикле средства защиты динамического кода предусмотрены.
ну и в перле я его в eval завернул (что тоже что твой catch) и в перле
есть рестриктед перл-песочница
Но судя по отзывам знающих людей до тиклевого варианта песочницы перловая не
дотягивает.
set replist [list to: {} :CV: {} ( { } ) { } : { } , { } \/ { } -> { } $ {} \[
{} \] {}]
совсем нифига не понятно. кстати если распихивать по функциям парсер
то нафиг в главном парсить аргументы? пусть каждая функция и разгребает
что ей там на вход пришло :)
код для беглого просмотра не годится, такой вариант получше:
set replist {
to: ""
:CV: ""
( " "
) " "
: " "
, " "
\/ " "
-> " "
$ ""
\[ ""
\] ""
}
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
