[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