[Moscow.pm] v2 просьба о ревью модуля DBIx::Struct

[Warstone@list.ru]

 Я, наверно, последний раз напишу, так как далее бессмысленно, очевидно...


Fri, 16 Jan 2015 10:34:02 +0100 от 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. На то, сколько программа будет занимать в памяти после того, как вы все нагенерите. Хотя ладно, это придирка. Могу еще одну рассказать... Вы пользуете DBIx::Connector, который в себе при создании имеет следующее: $self->{pid} = $$; Прощай форк после вашего populate'а. Прощай здравый смысл. Хотя это не ваша вина, но анализировать модули, которые используете - имеет смысл.
>> 2) Теряете возможность рантаймого похачить базовый класс или сделать
>> инъектирование к наследование, если уж вы не хотите mro::c3 с next::method
>> пользовать и таким образом давать возможность пользовать миксины, если
>> ОЧЕНЬ надо. 
>
>Use Case какой? Perl -- язык динамический, в рантайме можно что угодно 
>сделать. Сделать "просто". Если мне не допустим надо сделать аудит в моем варианте я перебиваю базовые методы в Base пакете. В вашем мне надо по всей схеме пройтись. Это для примера.
>> 3) Теряете читабельность кода
>
>Кода, который пользуется этим модулем? Я приводил примеры, там было, по моему 
>мнению, наоборот. Если речь про код модуля, то, Вы часто лезете под капот 
>машины, чтобы проверить красоту устройства двигателя? Кроме того, не такой уж 
>он нечитабельный, при достаточной подготовке читателя.
Я всегда лезу под капот машины, чтобы понять насколько она быстрая и не будет-ли у меня проблем с этой моделью. Я могу не понимать всего алгоритма работы, но примерное поведение я должен знать. Более того, нету лучше метода узнать что делает модуль, чем посмотреть на его код. И у нас такие все. В резульатте рождается что-то типа вот этого:  http://search.cpan.org/~randir/Class-Accessor-Inherited-XS-0.07/lib/Class/Accessor/Inherited/XS.pm (Автор не я, сразу говорю. Он метрах в 10 от меня сидит. Просто у него было время для того, чтобы это сделать).
А если мне еще надо и подготовиться... Я лучше подготовлюсь путем неиспользования модуля, особенно если у него есть альтернативы (DBIx::Simple + SQL::Abstract, у которых так-же есть проблемы с форками, кстати).
>> 4) Выигрываете мизерный процент на обращении к хешу.
>
>В плане скорости, да, это микрооптимизация, которая глобально может и не 
>влиять. А в плане расхода памяти это уже заметная разница. Был у меня в 
>далёком прошлом случай, когда пришлось переделать структуру строки с хеша на 
>массив, чтобы анализируемые данные стали влезать в память.
Ну куда вы полезли?.. Доступ к хешу в классе. Вы экономите чуть-чуть на кждом созданном классе таким образом, а не объекте.
>> И вы считаете это плюсом? Если вы где-то используете кодогеренацию вы что-то
>> делаете не так.
>
>Это похоже на постулат некоторой веры. Ну и на что же мне _динамический_ язык 
>тогда? А для вас динамический - это только eval? Ну тогда да. Если-же нет, то создание пакета в рантайме без евала - это тоже динамика.
>> Вам надо еще? Хорошо... Почему вы в коде где-то пользуете ссылку на CORE, а
>> где-то нет? Вы в своем модуле, что defined и exists перебили? Или... Зачем
>> это вообще? Причем в части коде есть CORE:: перед ref, в части нету...
>
>Если существует таблица, у которой есть поле "ref". Использование выражения 
>ref $a в коде объекта при наличии аксессора ref() у объекта приведёт к 
>неоднозначностям. Поэтому, в генерируемом коде постарался везде прописать явно 
>CORE::. Вопрос не почему вы это сделали, а почему вы это сделали не везде. Но тут возможно просто не нашли все, так как текст, а не код... А теста такого вы не набросали, похоже... B::Deparse попользуйте думаю узнаете немного интересного.
>> Вы проверяете во время setup_row есть-ли у вас уже такой класс, только вот
>> вы получаете имя класса и таблицу, а отдаете только имя класса... То есть я
>> никоем образом не узнаю, что я 2й раз пытаюсь вызвать генерацию класса, и
>> фиг с ним, если на одной и той-же таблице, а если на разных? Где там
>> проверка на название таблицы и гроханье с большим ором, если она не такая.
>> Где варн, если таблица та-же? Или это тренд такой "Если программист чего-то
>> ступил, давайте ему максимально осложним поиск баги"?
>
>Я немного не понял проблемы. Проверяется существование класса по таблице 
>символов, известной интерпретатору. Если класс есть, он используется, если 
>нет, то генерируется. Генерация происходит один раз для каждой таблицы при 
>коннекте, который происходит при стартапе приложения. Так же генерация 
>происходит для динамических запросов, тоже только один раз, второй раз 
>используется готовый класс. Проблема вот в этом: setup_row('table1', 'MySchema::Table'); setup_row('table2', 'MySchema::Table'). На 2-м должен упасть. У вас не падает.
----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150116/5821e027/attachment-0001.html>