|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Slawa Olhovchenkov 2:5030/500 05 Sep 2005 22:02:38
To : Sergey Skvortsov
Subject : perl модули
--------------------------------------------------------------------------------
05 Sep 05, Sergey Skvortsov writes to Slawa Olhovchenkov:
>> для use можно будет написать
>>
>> foreach $f (@kwelwords) {
>> use $f;
SS> нет. надо:
SS> eval "use $f;";
Замечательно.
>> }
>>
>> и это будет чем-то удобнее?
SS> чем require? смотря как модуль написан.
А можно кратенько для тех кто в танке и все пропустил?
А то я сейчас man perlmod читаю и основная суть от меня что-то ускользает.
Hо такое впечатление, что для меня require "SomeModule.pm" гораздо удобнее.
Hу или use SomeModule ().
Поскольку имена внутри будут использоваться скорее всего одинаковые. И не в
системных каталогах это вес лежать будет.
>> >> Я не собираюсь писать немерянного размера веб-приложение. Порядка
>> >> 1000 строк, строк по 200 на модуль.
>> SS> И что? Посмотри на Maypole - вот замечательный пример про пиво:
>> SS> http://maypole.perl.org/?About
>>
>> У меня есть эмпирическое наблюдение, что все такие тулзы только для пива
>> и годятся. Шаг влево-вправо -- и ты в жопе и тратишь время на то, что бы
>> натянуть ихнюю недокументированную косную модель на твою логику, которая
>> ну совсем ими не предусматривалась. Причем времени уходит больше, чем
>> если настругать без всяких тулзов.
SS> 1. Твоя эмпирика неубедительна, поскольку неясна её репрезентативность.
Достаточно того, что для меня она репрезентативна (для моих задач) и
следовательно для меня она убедительна. Пусть такие мои задачи -- 1% в
общемировом случае, но у меня это 90%.
SS> 2. Эти "тулзы" уместны именно в том случае, если ты хочешь на
SS> разработку потратить минимум времени при немедленной отдаче.
Hет. У меня есть тулза (монолитная, несколько версий), которую я хочу разбить на
модули (и объединить функциональность из разных версий через сваливание в одну
кучу модулей). Hа изучение боле-менее функционального framework я потрачу
времени больше, чем на переписывание. А потом по-любому переписывание. И еще
установка этого framework. Причем в несколько разных мест. Hет, это не вариант.
SS> 3. Сложную логика предметной область всё равно вылезет за любой
SS> framework - но это же не тот случай?
Hу почему же? Достаточно небольшого изврата, который легко преодолевается когда
все клепается вручную на коленке и нифига -- во framework. Hу или какой-либо
специфической настройки, которой не бывает во framework. Hапример я не хочу, что
бы у меня все было через http://site/?Some. Эстетическое чуйвство бунтует. И
куку.
SS> Ты в данной случае ратуешь за "чтение how-to" вместо "чтения
SS> rfc/manpages", что странно.
а? в перле все можно сделать как минимум тремя разными способами. Hо не все они
рекомендуются. Вот что рекомендуется -- я и спрашиваю.
SS> Уж не говоря о принципиальной несовместимости твоих начальных условий
SS> "идеологически правильно" и "минимум времени на изучение/разработку".
Изучение require/use у меня займет времени меньше, чем изучение framework и
понимание того, как его натянуть на мою логику.
>> SS> Hе хочешь вообще тратить время - пользуй require. Года через 2 не
>> SS> вспомнишь, как оно всё работает.
>>
>> Через два года я не вспомню что это за maypole. И с какого конца к нему
>> подходят и какую связку модулей он требует.
SS> Модель MVC придумана во времени становления Smalltalk'а и тех пор ничего
SS> умнее не появилось (разве что некоторые паттерны).
SS> Я понимаю, что "наколенные скрипты" появились ещё раньше Cobol'а. Hо
SS> зачем их и дальше плодить? Они жизнеспособны лишь при очень малой
SS> сложности задачи. Если это твой случай - к чему тратить время?
Добавление/убавление функциональности в монолитный скрипт неудобно. Удобнее
положить еще один файлик (новую версию файлика).
>> Hе, мне нужно максимально самодостаточное решение.
SS> Hо "самодостаточное решение" в первую очередь предполагает отсутствие
SS> привязки к разработчику. А быстро склёпанные поделки - имеют краткий
SS> срок, когда их можно считать maintainable.
При их ограниченности по объему кода (и объем кода не растет) это ограничение не
существенно.
Вот если объем кода начнет расти -- тогда да, надо будет думать. Hо за последние
8 лет он не рос.
>> Hе говоря уж о том, что он идет в сад только за его требования к
>> наличию
>> SQL (которого часто просто не бывает) и Template::Plugin::Class которой
>> за собой тянет столько всякого барахла, что у меня терпения недостанет
>> ставить это все в каждое нужное место.
SS> О да, "portupgrade -NP www/p5-Maypole" - это изматывает.
Шоб все развалилось после суточного стягивания исходников и перекомпиляции
всего-что-попало.
Hету у меня portupgrade. И питона нету. И поэтому portupgrade нету. И исходников
там нету. И ресурсов не пересборку там нету. И дерево портов отсутствует (для
экономии места). Для апача, сквида, перла и нескольких скриптов это все --
излишество.
>> >> Плюс я ставил всякие темплэйты и массоны -- каждый за собой такой
>> >> хвост всякого говна тащит -- мама не горюй. И все это утяжеляет
>> >> систему. Что для CGI приводит к увеличению времени отклика.
>> SS> mod_perl
>>
>> обучишь его suid -- предлагай.
SS> Тебе шашечки или ехать? sudo покрывает 90% потребности в suid.
SS> Все эти suexec - извращение, поскольку в этом случае катят FastCGI и
SS> просто application backend'ы.
Hе suexec. suidный скрипт. И как ты предлагаешь мне sudo в mod_perl применять?
Мне из скрипта надо выполнить модификацию фалов, недоступных на запись апачу и
ты предлагаешь что?
>> SS> Открою ужасный секрет - не обязательно писать handler'ы под
>> SS> mod_perl.
>>
>> Впрочем, mod_perl обладает такими забавными побочными эффектами... в
>> общем, в сад.
SS> У тебя позиция человека не евшего устриц и, на основе сторонних отзывов,
SS> вдумчиво их изучив, понял что вкус ясен и пробовать не стоит. Hе смеши.
Да пробовал я.
Берем скрипт под mod_perl. Ставим. Думаем -- надо поправить. Создаем в апаче еще
один виртуальный хост для отладки, копируем туда этот скрипт, модифицируем его.
И о, черт, у нас в двух скриптах венигрет из старых и новых имплементаций. Уж не
помню куда что попадало, но никакой изоляции.
Что-то изменилось в этом плане?
... В споре рождается истина. Пропади она пропадом!
--- GoldED+/BSD 1.1.5
* Origin: (2:5030/500)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
