Я, наверно, последний раз напишу, так как далее бессмысленно, очевидно...
Fri, 16 Jan 2015 10:34:02 +0100 от PEF Secure <[email protected]>: >On Friday, January 16, 2015 04:18:39 [email protected] 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-м должен >упасть. У вас не падает.
-- Moscow.pm mailing list [email protected] | http://moscow.pm.org
