[Moscow.pm] v2 просьба о ревью модуля DBIx::Struct
Dmitry Eremeev
dmitry на eremeev.ru
Пт Янв 16 01:36:54 PST 2015
"Не ссорьтесь, девочки".
Yours
Dmitry Eremeev
CEO adPremium
Russia / office: +7 499 703 32 07
UK / office: +44 870 295 24 46
Skype: eremeev.ru
https://linkedin.com/in/dimkae
https://facebook.com/dimkae
> 16 янв. 2015 г., в 12:34, PEF Secure <pef-secure на yandex.ru> написал(а):
>
>> On Friday, January 16, 2015 04:18:39 Warstone на list.ru wrote:
>> То есть вместо того чтобы использовать Class::XSAccessor который
>> оптимизирован по самое не балуйся вы используете eval, тем самым:
>
> Аксессоры -- малая часть того, что требуется. Если б только это, я бы обошёлся
> Class::Struct.
>
>> 1) Раздуваете working-set приложения
>
> Простите, но что именно раздувается? Я не понял, особенно учитывая мой ответ
> на п.4.
>
>> 2) Теряете возможность рантаймого похачить базовый класс или сделать
>> инъектирование к наследование, если уж вы не хотите mro::c3 с next::method
>> пользовать и таким образом давать возможность пользовать миксины, если
>> ОЧЕНЬ надо.
>
> Use Case какой? Perl -- язык динамический, в рантайме можно что угодно
> сделать.
>
>
>> 3) Теряете читабельность кода
>
> Кода, который пользуется этим модулем? Я приводил примеры, там было, по моему
> мнению, наоборот. Если речь про код модуля, то, Вы часто лезете под капот
> машины, чтобы проверить красоту устройства двигателя? Кроме того, не такой уж
> он нечитабельный, при достаточной подготовке читателя.
>
>
>> 4) Выигрываете мизерный процент на обращении к хешу.
>
> В плане скорости, да, это микрооптимизация, которая глобально может и не
> влиять. А в плане расхода памяти это уже заметная разница. Был у меня в
> далёком прошлом случай, когда пришлось переделать структуру строки с хеша на
> массив, чтобы анализируемые данные стали влезать в память.
>
>
>> И вы считаете это плюсом? Если вы где-то используете кодогеренацию вы что-то
>> делаете не так.
>
> Это похоже на постулат некоторой веры. Ну и на что же мне _динамический_ язык
> тогда?
>
>> Вам надо еще? Хорошо... Почему вы в коде где-то пользуете ссылку на CORE, а
>> где-то нет? Вы в своем модуле, что defined и exists перебили? Или... Зачем
>> это вообще? Причем в части коде есть CORE:: перед ref, в части нету...
>
> Если существует таблица, у которой есть поле "ref". Использование выражения
> ref $a в коде объекта при наличии аксессора ref() у объекта приведёт к
> неоднозначностям. Поэтому, в генерируемом коде постарался везде прописать явно
> CORE::.
>
>> Вы проверяете во время setup_row есть-ли у вас уже такой класс, только вот
>> вы получаете имя класса и таблицу, а отдаете только имя класса... То есть я
>> никоем образом не узнаю, что я 2й раз пытаюсь вызвать генерацию класса, и
>> фиг с ним, если на одной и той-же таблице, а если на разных? Где там
>> проверка на название таблицы и гроханье с большим ором, если она не такая.
>> Где варн, если таблица та-же? Или это тренд такой "Если программист чего-то
>> ступил, давайте ему максимально осложним поиск баги"?
>
> Я немного не понял проблемы. Проверяется существование класса по таблице
> символов, известной интерпретатору. Если класс есть, он используется, если
> нет, то генерируется. Генерация происходит один раз для каждой таблицы при
> коннекте, который происходит при стартапе приложения. Так же генерация
> происходит для динамических запросов, тоже только один раз, второй раз
> используется готовый класс.
>
>> Вы хотели ревью - вот он вам. Модуль выбросить или переписать по
>> нормальному, а не через... кодогенерацию. Сейчас модуль безнадежен с точки
>> зрения дальнейшего развития и использования. Его просто опасно
>> использовать.
>
> Всё опасно использовать. Даже регексп может вызвать rm -rf. За обсуждение и
> мнение -- спасибо.
> --
> PEF Developer
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
Подробная информация о списке рассылки Moscow-pm