• Почему в Perl так редко используется IoC, DI и магическая пилюля Kaiten::Container
    0
    Я еще как адекватно реагирую на критику! :) Пошел за обрезом :)

    Сегодня в ночи перечитал Фаулера еще раз, и познал Дао. Вроде бы получается так, если совсем на пальцах:
    — Registry & Service Locator — это тупо внешний для модулей хеш, с которым работает application (и никогда не модули, еcли по классике)
    — Dependency Injection — это тупо свойство самого модуля (это если прям по Ф.), выражающееся в том, что нужную ЕМУ зависимость модуль ждет свыше(через конструктор, сеттер или интерфейс), а не стоит сам.

    И то и другое по Ф. является IoC, с точки зрения application, т.к. измененяется привычная канва построения логики.

    Соответственно, понятие «DI фреймверка» по сути дела означает, что мы создаем наши классы не обычным путем, а с костылями. И без этих костылей оно упадет. И уже готовые классы не обладаюшие DI-свойствами, туда не запихнуть без изменений. Если по тупому — это source filter или препроцессор, строящий дополнительный код.

    Получается, что в perl DI фреймверк по сути не нужен, т.к. интерфейсов нет, а значит авто-разрешения (на уровне модуля) не будет, а без этого смысла в каком-то фремверке нет, ведь только-то и надо, что в классе вместо
    my $dbh = DBI->new();
    надо написать
    my $dbh = shift;


    И теперь плавно еще раз к топиксабжу — вот вернитесь к этому примеру — habrahabr.ru/blogs/perl/134891/#comment_4480367 и не противореча самому себе в абзаце

    IoC контейнеры исповедуют другую идеологию. Классы реализуют простейший механизм внедрения зависимостей — через конструктор, реже через сеттер.

    попробуйте объяснить мне, чем мы не IoCC для DBI, который принимает DBD как атрибут конструктора?
    Дальше —
    При этом контейнер самостоятельно (это важно), на основе конфига, прокидывает зависимости в ничего не подозревающие объекты, поэтому такой подход называется push.

    Да какая фик разница, как контейнер получает конфиг? Снаружи или читает сам — результат-то один и тот же. И как можно называть объекты «ничего не подозревающими», если они в курсе своей зависимости от инжекта? Ничего не подозревающими они будут если вы снаружи насильно перезагрузите конкретный (здесь — антоним абстрактного) конструктор ну или добавите сеттер, которого раньше не было.

    PS. Для меня эти архитектурные дебри стойко ассоциируются с дебатами вокруг «Вороне как-то бог послал кусочек сыра» с целью выяснить, какой именно бог, и являлась ли ворона прихожанкой именно этой церкви, как был осуществлен «посыл» сыра — прямым телепортом, сотворением или результатом действия третьих лиц, размером кусочка и, что немаловажно, сортом сыра. Уж простите :)
  • Почему в Perl так редко используется IoC, DI и магическая пилюля Kaiten::Container
    0
    showmethecode
  • Почему в Perl так редко используется IoC, DI и магическая пилюля Kaiten::Container
    0
    Что вы подразумеваете под «модульные тесты на хендлеры»? Хендлер есть экземпляр класса или литерал, литералы тестировать смысла нет, а как классы тестировать все в курсе. Ну я уж молчу, что у нас еще и probe есть, который «не отходя от кассы» тестирует хендлер.
  • Почему в Perl так редко используется IoC, DI и магическая пилюля Kaiten::Container
    0
    Т.е. я верно понимаю, чтобы у нас было «IoCC — push» нам нужен контейнер, в котором на момент его запуска гвоздями прибито все, что ему может пригодится?
    Если я не прав — можно коротенький пример или ссылку?
  • Почему в Perl так редко используется IoC, DI и магическая пилюля Kaiten::Container
    0
    Ну в общем как-то так это выглядит в «причесанном» варианте.

    github.com/Meettya/Kaiten-Container/blob/master/ex/change_engine_example.pl

    Теперь это пример тоже кусок теста. Все в суп дело, все в дело.
  • Почему в Perl так редко используется IoC, DI и магическая пилюля Kaiten::Container
    +1
    Хороший вопрос.
    Действительно, в таком случае мне нужен интерфейсный модуль, по-другому транслировать разноименные методы кажется и не получится.
    Как-то примено так — gist.github.com/1505271

    Но! если для тестирования приложения мы откатывамся на LoggerEngine — реализация ILogger нам уже не нужна. Вся логика может быть оставлена, а модуль отсутствовать — контейнер в состоянии эмулировать (не слишком умно, но все же) интерфейс.
    Вот такми образом — gist.github.com/1505295

    Да, как вы понимаете, все вызовы add(*Logger) в main только для наглядности, ничто не мешает выкинуть их в ClobalConstructor, и подключать их там, в процессе create_container, после создания основной базы.

    В таком случае все изменения затронут только ClobalConstructor + модуль ILogger, ничего не попишешь, внести изменения ТОЛЬКО в одном месте не получится.
  • Почему в Perl так редко используется IoC, DI и магическая пилюля Kaiten::Container
    +2
    Нет, это не «просто «красивая обёртка над синглтоном» со списком хэндлеров».
    Это синглтон, DI контейнер, абстракный интерфейс, система тестирования компонентов — все вместе или каждое по отдельности. Что захотите, то делать и будет.

    Еще раз попытаюсь объяснить — я не говорю «интерфейс отстой», я говорю «KC сам по себе абстракный интерфейс, ему не нужны обертки ниже по течению».

    Потом — компоненты могут быть связаны, могут быть изолированны. Сами решаете. Если зависимость не разрешена — все умрет. Пазрешаена одна из сотни и вы пользуетесь только ей — оно будет работать. И ничто не мешает собрать большую систему из этих компонентов, зависимости внутри которых разрешены на 1%, если это тот процент, что вам нужен. Для теста, к примеру.
  • Почему в Perl так редко используется IoC, DI и магическая пилюля Kaiten::Container
    +2
    Спасибо за коммент.

    Вот тут накидал небольшой примерчик с использованием KC github.com/Meettya/Kaiten-Container/blob/master/ex/simple_example.pl

    Суть в чем — интерфейс можно реализовать отдельным враппером, и отдавать в контейнер враппер, а в нем (враппере) — реализовывать обертку, но по мне это пустой перевод байтов.

    Можно поступить намного проще — дать САМОМУ контейнеру решать, что отдавать, сделав обертку над КОНТЕЙНЕРОМ. Причем при его использовании, в тестах например, нужно разрешить только те зависимости, которые используются. То, что не используется просто игнорируется, они не требуются для работы самого контейнера.

    Можно подсунуть mock, если что-то слишком громоздко для реализации, подменив любой хендлер.

    Т.е. реально мое решение БОЛЕЕ демократично, чем интерфейс. Оно не настаивает на реаоизации всего и работает по принципу «позднего связывания».

    Или я чего-то еще не понял?
  • Почему в Perl так редко используется IoC, DI и магическая пилюля Kaiten::Container
    0
    А если не приведу — в угол поставите? :)

    Модуль сделан поди сегодня, какая разработка? Прикручивание в процессе, может как-нить и покажу. Если Вам все еще будет интересно.
  • Почему в Perl так редко используется IoC, DI и магическая пилюля Kaiten::Container
    0
    так для легкости DI и был написан сабжевый модуль :)

    изменять-то быстрее, но, право слово, это не повод для хардкода и прочей ереси.
    DI дает гибкость и меньшую связанность.
  • Почему в Perl так редко используется IoC, DI и магическая пилюля Kaiten::Container
    0
    А чем отличается интерпретируемый язык от компилируемого, если вы не используете генерацию кода «на лету»?
  • Почему в Perl так редко используется IoC, DI и магическая пилюля Kaiten::Container
    +1
    Владение методиками IoC и DI очищает карму, а строчный eval — авидья и еще больше раскручивает колесо сансары.
  • Почему в Perl так редко используется IoC, DI и магическая пилюля Kaiten::Container
    +1
    О, спасибо за классный ответ.

    Ну, начнем с того, что в решении проблемы не возникает.
    1. Остановитесть в одном шаге от класса, который не должен зависеть от контейнера, выньте из него (контейнера) все что вам нужно и стройте по классической схеме.
    2. Не вижу разницы между кодом подготовки контейнера и классическим вариантом, вы же в одном месте все собираете.
    3. Типа да? В смысле с чего такой странный вывод? Ни одна подсистема не «стрельнет», пока ее не вызовут, явно или в deep dependicies resolving, коя есть с версии 0.25.

    Что до тестирования — соберите с Mock- ами или поменяйте один из хендлеров на нужный Вам, делов-то.

    KC теперь поддерживает кострукции типа

        my $config = {
             examplep_config => {
                handler  => sub { { RaiseError => 1 } },
                probe    => sub { 1 },
                settings => { reusable => 1 },
             },
             examplep_dbd => {
                handler  => sub { "dbi:ExampleP:" },
                probe    => sub { 1 },
                settings => { reusable => 1 },      
             },
             ExampleP => {
                 handler  => sub { 
                    my $c = shift;
                    my $dbd = $c->get_by_name('examplep_dbd');
                    my $conf = $c->get_by_name('examplep_config');
                    return DBI->connect( $dbd, "", "", $conf ) or die $DBI::errstr;
                  },
                 probe    => sub { shift->ping() },
                 settings => { reusable => 1 }
             },
        };
    


    Делаете remove-add и все.

    В случае с Dipendency Injection мы передаем все зависимости в класс снаружи

    Вот посмотрите еще раз на пример и объясните, где я делаю по-другому?
    Мы строим ExampleP хендлер, нычим его и достаем потом, как он понадобится.
    типа
        my $dbh = $container->get_by_name('ExampleP');
        my $person = Person->new( dbh => $dbh );
    


    Просто хендлер может и не понадобится, тогда он и НЕ отработает. Или его далеко тащить надо. Вот и все.
  • Почему в Perl так редко используется IoC, DI и магическая пилюля Kaiten::Container
    0
    Тут профит какой — можно где-то в начале спокойно взять данные из конфигурации СИСТЕМЫ, наляпять ВСЕ хендлеры, которые нуждаются в конфигурировании или сложны в построении и положить их в контейнер.
    Потом просто пробрасываем контейнер туда, где он нужен (в аргументах вызова ли, создав синглтон с ним — не суть дела) и вынимаем из него готовый НУЖНЫЙ хендлер, вся бодяга с конфигурированием и прочим нам уже не нужна.
    Вот как-то так.
  • Почему в Perl так редко используется IoC, DI и магическая пилюля Kaiten::Container
    +1
    суть в том, что дважды вызвав $container->get_by_name('ExampleP') можно получить:
    — один и тот же хендлер, если используется reusable => 1 и при втором вызове то, что у нас было сделано первый раз пройдет проверку |probe|
    — два РАЗНЫХ хендлера, если не используется reusable или результат первого вызова не прошел проверку |probe| (ну мало ли, база отвалились)

    Можно еще рассмативать эту штуку как универсальную фабрику, наверное.
  • Почему в Perl так редко используется IoC, DI и магическая пилюля Kaiten::Container
    0
    А! понял вопрос. Кажется.
    Вызов выражения.
    В момент описания конфига мы кладем полуфабрикат, он сырой.
    В момент вызова get_by_name полуфабрикат размораживается.
    Т.е. код НЕ будет исполнен до тех пор, пока его не вызовут в первый раз.
  • Почему в Perl так редко используется IoC, DI и магическая пилюля Kaiten::Container
    +2
    Работайте лучше и не гневите главного, а то в аду будете писать на JS без фреймверков!
  • Natural Docs + GitHub Pages = online auto-documentation на халяву (почти)
    +2
    оно не виноватое, хабра меня подставило :)
  • Natural Docs + GitHub Pages = online auto-documentation на халяву (почти)
    0
    Упс, хабр подложил мне свинью.
    Давал ошибку Sql, а сам посты сохранял.
    Сорри all.
  • Natural Docs + GitHub Pages = online auto-documentation на халяву (почти)
    0
    Расшифровать-то можно. но придется вдаваться в дебри того, что есть object и tree в git.
    Попробуйте посмотреть book.git-scm.com/1_the_git_object_model.html и www.gitguys.com/topics/git-object-tree/.
    Если коротко, то мы HEAD gh-pages ветви объявляем как ссылку на doc, который является одним из объектов нашего нового коммита — HEAD в ветке master. Деревья, корень дерева (gh-pages) как ссылка на ветвь(doc) другого дерева(master) — такая концепция, я не знаю как это можно проще представить.

    >rm .git/index
    >git clean -fdx
    когда мы создаем новый brunch, то в нем есть все то, что и в родителе — т.е. это будет копия, а нам все эти документы не нужны. поэтому мы чистим его, удаляя из него все вообще.
    так понятнее?
  • Natural Docs + GitHub Pages = online auto-documentation на халяву (почти)
    0
    Расшифровать-то можно. но придется вдаваться в дебри того, что есть object и tree в git.
    Попробуйте посмотреть book.git-scm.com/1_the_git_object_model.html и www.gitguys.com/topics/git-object-tree/.
    Если коротко, то мы HEAD gh-pages ветви объявляем как ссылку на doc, который является одним из объектов нашего нового коммита — HEAD в ветке master. Деревья, корень дерева (gh-pages) как ссылка на ветвь(doc) другого дерева(master) — такая концепция, я не знаю как это можно проще представить.

    >rm .git/index
    >git clean -fdx
    когда мы создаем новый brunch, то в нем есть все то, что и в родителе — т.е. это будет копия, а нам все эти документы не нужны. поэтому мы чистим его, удаляя из него все вообще.
    так понятнее?
  • Natural Docs + GitHub Pages = online auto-documentation на халяву (почти)
    0
    Расшифровать-то можно. но придется вдаваться в дебри того, что есть object и tree в git.
    Попробуйте посмотреть book.git-scm.com/1_the_git_object_model.html и www.gitguys.com/topics/git-object-tree/.
    Если коротко, то мы HEAD gh-pages ветви объявляем как ссылку на doc, который является одним из объектов нашего нового коммита — HEAD в ветке master. Деревья, корень дерева (gh-pages) как ссылка на ветвь(doc) другого дерева(master) — такая концепция, я не знаю как это можно проще представить.

    >rm .git/index
    >git clean -fdx
    когда мы создаем новый brunch, то в нем есть все то, что и в родителе — т.е. это будет копия, а нам все эти документы не нужны. поэтому мы чистим его, удаляя из него все вообще.
    так понятнее?
  • Natural Docs + GitHub Pages = online auto-documentation на халяву (почти)
    0
    Расшифровать-то можно. но придется вдаваться в дебри того, что есть object и tree в git.
    Попробуйте посмотреть book.git-scm.com/1_the_git_object_model.html и www.gitguys.com/topics/git-object-tree/.
    Если коротко, то мы HEAD gh-pages ветви объявляем как ссылку на doc, который является одним из объектов нашего нового коммита — HEAD в ветке master. Деревья, корень дерева (gh-pages) как ссылка на ветвь(doc) другого дерева(master) — такая концепция, я не знаю как это можно проще представить.

    >rm .git/index
    >git clean -fdx
    когда мы создаем новый brunch, то в нем есть все то, что и в родителе — т.е. это будет копия, а нам все эти документы не нужны. поэтому мы чистим его, удаляя из него все вообще.
    так понятнее?
  • Natural Docs + GitHub Pages = online auto-documentation на халяву (почти)
    0
    Расшифровать-то можно. но придется вдаваться в дебри того, что есть object и tree в git.
    Попробуйте посмотреть book.git-scm.com/1_the_git_object_model.html и www.gitguys.com/topics/git-object-tree/.
    Если коротко, то мы HEAD gh-pages ветви объявляем как ссылку на doc, который является одним из объектов нашего нового коммита — HEAD в ветке master. Деревья, корень дерева (gh-pages) как ссылка на ветвь(doc) другого дерева(master) — такая концепция, я не знаю как это можно проще представить.

    >rm .git/index
    >git clean -fdx
    когда мы создаем новый brunch, то в нем есть все то, что и в родителе — т.е. это будет копия, а нам все эти документы не нужны. поэтому мы чистим его, удаляя из него все вообще.
    так понятнее?
  • Natural Docs + GitHub Pages = online auto-documentation на халяву (почти)
    0
    Расшифровать-то можно. но придется вдаваться в дебри того, что есть object и tree в git.
    Попробуйте посмотреть book.git-scm.com/1_the_git_object_model.html и www.gitguys.com/topics/git-object-tree/.
    Если коротко, то мы HEAD gh-pages ветви объявляем как ссылку на doc, который является одним из объектов нашего нового коммита — HEAD в ветке master. Деревья, корень дерева (gh-pages) как ссылка на ветвь(doc) другого дерева(master) — такая концепция, я не знаю как это можно проще представить.

    >rm .git/index
    >git clean -fdx
    когда мы создаем новый brunch, то в нем есть все то, что и в родителе — т.е. это будет копия, а нам все эти документы не нужны. поэтому мы чистим его, удаляя из него все вообще.
    так понятнее?
  • Natural Docs + GitHub Pages = online auto-documentation на халяву (почти)
    0
    Расшифровать-то можно. но придется вдаваться в дебри того, что есть object и tree в git.
    Попробуйте посмотреть book.git-scm.com/1_the_git_object_model.html и www.gitguys.com/topics/git-object-tree/.
    Если коротко, то мы HEAD gh-pages ветви объявляем как ссылку на doc, который является одним из объектов нашего нового коммита — HEAD в ветке master. Деревья, корень дерева (gh-pages) как ссылка на ветвь(doc) другого дерева(master) — такая концепция, я не знаю как это можно проще представить.

    >rm .git/index
    >git clean -fdx
    когда мы создаем новый brunch, то в нем есть все то, что и в родителе — т.е. это будет копия, а нам все эти документы не нужны. поэтому мы чистим его, удаляя из него все вообще.
    так понятнее?
  • Natural Docs + GitHub Pages = online auto-documentation на халяву (почти)
    0
    Расшифровать-то можно. но придется вдаваться в дебри того, что есть object и tree в git.
    Попробуйте посмотреть book.git-scm.com/1_the_git_object_model.html и www.gitguys.com/topics/git-object-tree/.
    Если коротко, то мы HEAD gh-pages ветви объявляем как ссылку на doc, который является одним из объектов нашего нового коммита — HEAD в ветке master. Деревья, корень дерева (gh-pages) как ссылка на ветвь(doc) другого дерева(master) — такая концепция, я не знаю как это можно проще представить.

    >rm .git/index
    >git clean -fdx
    когда мы создаем новый brunch, то в нем есть все то, что и в родителе — т.е. это будет копия, а нам все эти документы не нужны. поэтому мы чистим его, удаляя из него все вообще.
    так понятнее?
  • Natural Docs + GitHub Pages = online auto-documentation на халяву (почти)
    0
    Расшифровать-то можно. но придется вдаваться в дебри того, что есть object и tree в git.
    Попробуйте посмотреть book.git-scm.com/1_the_git_object_model.html и www.gitguys.com/topics/git-object-tree/.
    Если коротко, то мы HEAD gh-pages ветви объявляем как ссылку на doc, который является одним из объектов нашего нового коммита — HEAD в ветке master. Деревья, корень дерева (gh-pages) как ссылка на ветвь(doc) другого дерева(master) — такая концепция, я не знаю как это можно проще представить.

    >rm .git/index
    >git clean -fdx
    когда мы создаем новый brunch, то в нем есть все то, что и в родителе — т.е. это будет копия, а нам все эти документы не нужны. поэтому мы чистим его, удаляя из него все вообще.
    так понятнее?
  • Natural Docs + GitHub Pages = online auto-documentation на халяву (почти)
    0
    Расшифровать-то можно. но придется вдаваться в дебри того, что есть object и tree в git.
    Попробуйте посмотреть book.git-scm.com/1_the_git_object_model.html и www.gitguys.com/topics/git-object-tree/.
    Если коротко, то мы HEAD gh-pages ветви объявляем как ссылку на doc, который является одним из объектов нашего нового коммита — HEAD в ветке master. Деревья, корень дерева (gh-pages) как ссылка на ветвь(doc) другого дерева(master) — такая концепция, я не знаю как это можно проще представить.

    >rm .git/index
    >git clean -fdx
    когда мы создаем новый brunch, то в нем есть все то, что и в родителе — т.е. это будет копия, а нам все эти документы не нужны. поэтому мы чистим его, удаляя из него все вообще.
    так понятнее?
  • Natural Docs + GitHub Pages = online auto-documentation на халяву (почти)
    0
    Расшифровать-то можно. но придется вдаваться в дебри того, что есть object и tree в git.
    Попробуйте посмотреть book.git-scm.com/1_the_git_object_model.html и www.gitguys.com/topics/git-object-tree/.
    Если коротко, то мы HEAD gh-pages ветви объявляем как ссылку на doc, который является одним из объектов нашего нового коммита — HEAD в ветке master. Деревья, корень дерева (gh-pages) как ссылка на ветвь(doc) другого дерева(master) — такая концепция, я не знаю как это можно проще представить.

    >rm .git/index
    >git clean -fdx
    когда мы создаем новый brunch, то в нем есть все то, что и в родителе — т.е. это будет копия, а нам все эти документы не нужны. поэтому мы чистим его, удаляя из него все вообще.
    так понятнее?
  • Natural Docs + GitHub Pages = online auto-documentation на халяву (почти)
    0
    Расшифровать-то можно. но придется вдаваться в дебри того, что есть object и tree в git.
    Попробуйте посмотреть book.git-scm.com/1_the_git_object_model.html и www.gitguys.com/topics/git-object-tree/.
    Если коротко, то мы HEAD gh-pages ветви объявляем как ссылку на doc, который является одним из объектов нашего нового коммита — HEAD в ветке master. Деревья, корень дерева (gh-pages) как ссылка на ветвь(doc) другого дерева(master) — такая концепция, я не знаю как это можно проще представить.

    >rm .git/index
    >git clean -fdx
    когда мы создаем новый brunch, то в нем есть все то, что и в родителе — т.е. это будет копия, а нам все эти документы не нужны. поэтому мы чистим его, удаляя из него все вообще.
    так понятнее?
  • Natural Docs + GitHub Pages = online auto-documentation на халяву (почти)
    0
    Расшифровать-то можно. но придется вдаваться в дебри того, что есть object и tree в git.
    Попробуйте посмотреть book.git-scm.com/1_the_git_object_model.html и www.gitguys.com/topics/git-object-tree/.
    Если коротко, то мы HEAD gh-pages ветви объявляем как ссылку на doc, который является одним из объектов нашего нового коммита — HEAD в ветке master. Деревья, корень дерева (gh-pages) как ссылка на ветвь(doc) другого дерева(master) — такая концепция, я не знаю как это можно проще представить.

    >rm .git/index
    >git clean -fdx
    когда мы создаем новый brunch, то в нем есть все то, что и в родителе — т.е. это будет копия, а нам все эти документы не нужны. поэтому мы чистим его, удаляя из него все вообще.
    так понятнее?
  • Natural Docs + GitHub Pages = online auto-documentation на халяву (почти)
    0
    Расшифровать-то можно. но придется вдаваться в дебри того, что есть object и tree в git.
    Попробуйте посмотреть book.git-scm.com/1_the_git_object_model.html и www.gitguys.com/topics/git-object-tree/.
    Если коротко, то мы HEAD gh-pages ветви объявляем как ссылку на doc, который является одним из объектов нашего нового коммита — HEAD в ветке master. Деревья, корень дерева (gh-pages) как ссылка на ветвь(doc) другого дерева(master) — такая концепция, я не знаю как это можно проще представить.

    >rm .git/index
    >git clean -fdx
    когда мы создаем новый brunch, то в нем есть все то, что и в родителе — т.е. это будет копия, а нам все эти документы не нужны. поэтому мы чистим его, удаляя из него все вообще.
    так понятнее?
  • Natural Docs + GitHub Pages = online auto-documentation на халяву (почти)
    0
    Расшифровать-то можно. но придется вдаваться в дебри того, что есть object и tree в git.
    Попробуйте посмотреть book.git-scm.com/1_the_git_object_model.html и www.gitguys.com/topics/git-object-tree/.
    Если коротко, то мы HEAD gh-pages ветви объявляем как ссылку на doc, который является одним из объектов нашего нового коммита — HEAD в ветке master. Деревья, корень дерева (gh-pages) как ссылка на ветвь(doc) другого дерева(master) — такая концепция, я не знаю как это можно проще представить.

    >rm .git/index
    >git clean -fdx
    когда мы создаем новый brunch, то в нем есть все то, что и в родителе — т.е. это будет копия, а нам все эти документы не нужны. поэтому мы чистим его, удаляя из него все вообще.
    так понятнее?
  • Natural Docs + GitHub Pages = online auto-documentation на халяву (почти)
    0
    Если бы я писал на python — возможно, но так как основной язык — perl, поддержки которого в sphinx я не нашел, то Natural Docs удобнее (да и выглядит привычнее).
  • Natural Docs + GitHub Pages = online auto-documentation на халяву (почти)
    0
    Нужно писать документацию ( а некоторые языки поддерживаются хуже других и писать приходится больше ) и попрыгать с бубном немного, чтобы все заработало — по-моему кой-какая плата присутствует.
  • Natural Docs + GitHub Pages = online auto-documentation на халяву (почти)
    0
    Вероятно в том, что без особого напряга получается приличная документация, с аналогом тегов, поиском и в html-формате. Которая, кроме всего прочего, лежит рядом с кодом и обновляется автоматом.
    Вам этого мало? :)
  • Производительность пакетов ООП в Perl
    0
    хм. оффтоп конечно, но что из приличной литературы по архитектуре ПО на русском посоветуете?
    Уж больно похоже на то, что в теме вы очень плотно, глупо не воспользоваться ситуацией и не спросить :)

    И еще один вопрос, если позволите — инверсия контроля и создание объекта-можордома, который строит и возвращает нам любые иные объекты (не совсем абстрактная фабрика, но что-то типа) — плохая идея? Что-то меня в ней смущает, а без нее никак не пойму правильного применения Bread::Board.

    PS. трехтомник Кнута для меня невкуряем.
  • Производительность пакетов ООП в Perl
    0
    ммм… идеально, но не получится. В программировании нет ничего простого, а разрезание на кучу маленьких частей не упрощает итоговое приложение, сложность просто «размазывается» + накладные расходы на взаимодействие (в сложностном смысле, не трогаем производительность).
    Кроме того не будем забывать, что приложения пишутся не сферическими программистами в ваккуме для самовыражения, а, в основном, по требованию бизнеса.
    А для бизнеса: быстрее и надежнее лучше, чем дешевле.

    с точки зрения бизнеса лучше гарантировано терять 5 штук баксов на еще один сервер, потому что медленно, чем неожиданно 50 штук, из-за того что внедренная фича все сломала или 500 штук, потому что требование не может быть реализованно архитектурно вообще.
  • Производительность пакетов ООП в Perl
    0
    С другой стороны, если подумать — Method::Signatures все же overkill. ИМХО пакет = класс, так к чему плодить сущности и упихивать все внутря, раздувая кавычечки?