Comments 17
Звучит настолько круто, что даже тяжело поверить. Особенно если у них получится встроить этот функционал без потери обратной совместимости.
На самом деле это звучит как картинка про «15 несовместимых стандартов плюс ещё один новый». Но если им удастся этот новый модуль засунуть в ядро, добиться чтобы он был действительно лёгким и быстрым (после реализации всех необходимых фич), и сагитировать народ активно на него переходить с Moose и Moo — тогда да, будет неплохо.
Хотя лично мне до сих пор хватало встроенных возможностей перла для реализации ООП, я даже в использовании Moo пока не чувствовал необходимости.
Хотя лично мне до сих пор хватало встроенных возможностей перла для реализации ООП, я даже в использовании Moo пока не чувствовал необходимости.
UFO just landed and posted this here
Не совсем. Или совсем нет. Mouse (как и Moose) — это уже готовые реализации объектных систем, в то время как mop — фреймворк для построения подобных систем. Если уж и было брать что–то из готового, то Class::MOP, но в начале статьи объясняется, почему этого делать не стали.
Речь не о том, чтобы просто разрешить разным системам «разговаривать» друг с другом через кучу костылей, а речь о том, чтобы задать стандарт (своего рода интерфейс) и базу для их написания.
Представим, что в версии перла 5.55 mop включили в стандартную библиотеку. Это будет означать, что в этот момент можно будет выкинуть Class::MOP и подобные модули, и переписать Moose, Mouse, и вообще все остальные Mo* модули (и не только) на основе mop. Это должно значительно упростить взаимодействие кода, построенного с помощью разных объектных систем.
Речь не о том, чтобы просто разрешить разным системам «разговаривать» друг с другом через кучу костылей, а речь о том, чтобы задать стандарт (своего рода интерфейс) и базу для их написания.
Представим, что в версии перла 5.55 mop включили в стандартную библиотеку. Это будет означать, что в этот момент можно будет выкинуть Class::MOP и подобные модули, и переписать Moose, Mouse, и вообще все остальные Mo* модули (и не только) на основе mop. Это должно значительно упростить взаимодействие кода, построенного с помощью разных объектных систем.
UFO just landed and posted this here
В стандартной поставке нужен
Вообще на счёт core modules, майнтайнеры perl думают о них немного иначе, чем юзеры (может раньше было подругому).
Core modules — это что нужно для существования самого perl, для его деплоя, установки, тестов, для и соответственно, для работы установщика CPAN, документации POD.
Так что самую, самую расчудесную библиотеку не будут включать, чтобы юзерам было веселее.
Ну, как раз эта формальная проблема решается тривиально — достаточно добавить пару классов в CPAN или perldoc использующих mop.
Я бы не сказал что это формальное правило, которое майнтайнеры хотят обойти, но сами не знают как.
Просто реально не хотят ничего пихать в ядро.
К тому же, всё что в ядре — должно использовать только модули в ядре, авторы некоторых модулей не хотят чтобы их модули добавляли в ядро и лишали их сводобы.
Так же майнтайнеры операционных систем постоянно давят на perl ( и на другие апстримы) и хотят уменьшить его размер (некоторые, например, RHEL пошли дальше, сами удалили модули из ядра, и perl в RHEL не настоящий, там нет многих core модулей, их нужно ставить отдельно). Видимо это связанно со всякими netinstall дистрибьютивами, которые влезают на огрызок cdrom и их хотят ещё больше уменьшить.
Просто реально не хотят ничего пихать в ядро.
К тому же, всё что в ядре — должно использовать только модули в ядре, авторы некоторых модулей не хотят чтобы их модули добавляли в ядро и лишали их сводобы.
Так же майнтайнеры операционных систем постоянно давят на perl ( и на другие апстримы) и хотят уменьшить его размер (некоторые, например, RHEL пошли дальше, сами удалили модули из ядра, и perl в RHEL не настоящий, там нет многих core модулей, их нужно ставить отдельно). Видимо это связанно со всякими netinstall дистрибьютивами, которые влезают на огрызок cdrom и их хотят ещё больше уменьшить.
UFO just landed and posted this here
Большое спасибо за статью, было интересно узнать об этом проекте, еще интереснее будет поиграть с ним.
А как в классе-наследнике оперировать с атрибутами его родителя?
Этот пост перевели на английский: blogs.perl.org/users/btyler/2013/10/a-metaobject-protocol-for-core-perl-5-translated-from-russian.html
Там в комментариях отметился Stevan Little, скорректировав фразу насчёт публичных/приватных атрибутов — он пишет, что в mop атрибуты приватные, как и в Perl6. cruxacrux, исправьте это в статье, плз.
Спасибо, поправил.
Этот момент я обдумывал, но меня смутило то, что в mop для таких атрибутов автоматически создаётся аксессор, т.е. позволяет обратиться к ним за пределами класса, в то время как в Perl 6 такого нет. Сейчас взглянул на пример класса в Perl 6 и понял, что спутал аксессор и непосредственный доступ к переменной — это разные вещи. В mop пока нет публичных атрибутов.
Этот момент я обдумывал, но меня смутило то, что в mop для таких атрибутов автоматически создаётся аксессор, т.е. позволяет обратиться к ним за пределами класса, в то время как в Perl 6 такого нет. Сейчас взглянул на пример класса в Perl 6 и понял, что спутал аксессор и непосредственный доступ к переменной — это разные вещи. В mop пока нет публичных атрибутов.
Sign up to leave a comment.
Metaobject Protocol для базового Perl 5