VO
Я бы подумал что из темплейта. Или базы
Size: a a a
2021 January 26
SZ
Да, почему бы нет? Если на момент формирования строки с произвольным кодом все переменные, упомянутые в нём, доступны, то eval $code_str же я могу сделать? :)
Если да, то евалить его надо там, откуда они видны
AK
А "произвольный код" приходит из командной строки?
В данном случае нет, поэтому ограничение и можно легко и некрасиво обойти
SZ
Да, почему бы нет? Если на момент формирования строки с произвольным кодом все переменные, упомянутые в нём, доступны, то eval $code_str же я могу сделать? :)
Ответ на твой вопрос утвердительный
AP
У меня такой кейс: нужно в конструктор объекта передать праметры командной строки, при этом eval конструктора делается раньше, чем появляется переменная my $opts. Но сделать так, чтобы код в eval "увидел" $opts невозможно.
нихрена не понял, но пахнет просто передачей параметров
SZ
нихрена не понял, но пахнет просто передачей параметров
++
AP
Должно работать так:
В принципе решается помещением пустого my $opt там же, сверху где-то, но выглядит это не очень.
Вопрос я больше для понимания сути задал, как это технически обойти/решить итак понятно.
Суть в том, что я не понимаю, в чём разница между:
1)
и
2)
defers auth_ldap => \'Authenticator::LDAP->new($opt->ldap_config)'При этом defers хочется вынести с декларативную часть кода (ближе к use и BEGIN {} ), а не вызывать уже после формирования my $opt'а
В принципе решается помещением пустого my $opt там же, сверху где-то, но выглядит это не очень.
Вопрос я больше для понимания сути задал, как это технически обойти/решить итак понятно.
Суть в том, что я не понимаю, в чём разница между:
1)
my $x = 'hello';
sub f { eval 'say $x' }
f()
и
2)
sub f { eval 'say $x' }
my $x = 'hello';
f()суть в связывании переменной. в первом случае в момент компиляции захватывается внешняя переменная, во втором компиляция не видит локальной переменной и компилируется со ссылкой на пакетную, потом уже не поменять.
AP
единственный вариант — компилировать в правильном порядке. либо вообще не пользоваться захватом переменных снаружи, передавать всё параметрами
VG
...героически победив захват, мужественно начать бороться с вызванными им утечками..
SZ
Забить х на всё и писать на шеллефорте
AP
В данном случае нет, поэтому ограничение и можно легко и некрасиво обойти
я могу тебе круче изврат подсказать. я ж тоже был когда-то упорным: я сорс фильтр писал.
SZ
я могу тебе круче изврат подсказать. я ж тоже был когда-то упорным: я сорс фильтр писал.
А можно было просто кейворд :р
AP
ну, у меня там хитро было. спец синтаксис
AP
хендлеры событий со спец прологом и эпилогом, пролог можно было составить стандартными "кирпичиками", можно с параметрами
AP
всё ради того, чтобы код писать было коротко и только по смыслу. в апи массы функций имеют одинаковые/однотипные параметры, их проверки совершенно однотипны, но при копи-пасте люди делают ошибки, плюс при проверке параметров можно получить какие-то данные и дальше использовать, универсальное однотипное логгирование всех дел... короче, было удобно.
AP
последствием того подхода можно считать вот этот модуль, который я максимально освободил от спец языка, что там был :) https://github.com/jef-sure/pef-prolog-github/blob/master/lib/PEF/Prolog.pod
AP
о, кстати, там я тоже обходил вопрос с порядком компиляции: переменные делаются пакетными (сорс фильтром) и локализуются перед вызовом собсна кода... в том проекте было не так, там весь хендлер генерировался целиком в одну функцию и такого изврата не требовалось...
AP
короче, очередной концепт...
2021 January 27
ВР
Как раз нет. Вы один раз создали, соединение протухло, но оно создано
Во. Кстати! О протухлостях соединений!
Кто-нибудь научился ли годным способом обнаруживать протухлость соединения с базой mysql?
use Mysql;
...
my $dbh = Mysql->Connect($host,$database,$password,$login);
...
ну тут такой работаешь с этим $dbh, никого не трогаешь, а сервер такой бац - или перезагрузился, или просто закрыл соединение, а мне ж об этом никто не сообщил и я ж наивно думаю, что с моим $dbh можно работать дальше. А тут давно не тут-то было уж...🤔
Кто-нибудь научился ли годным способом обнаруживать протухлость соединения с базой mysql?
use Mysql;
...
my $dbh = Mysql->Connect($host,$database,$password,$login);
...
ну тут такой работаешь с этим $dbh, никого не трогаешь, а сервер такой бац - или перезагрузился, или просто закрыл соединение, а мне ж об этом никто не сообщил и я ж наивно думаю, что с моим $dbh можно работать дальше. А тут давно не тут-то было уж...🤔