Metaobject Protocol для базового Perl 5

[@portsigar]

Звучит настолько круто, что даже тяжело поверить. Особенно если у них получится встроить этот функционал без потери обратной совместимости.

[@powerman]

На самом деле это звучит как картинка про «15 несовместимых стандартов плюс ещё один новый». Но если им удастся этот новый модуль засунуть в ядро, добиться чтобы он был действительно лёгким и быстрым (после реализации всех необходимых фич), и сагитировать народ активно на него переходить с Moose и Moo — тогда да, будет неплохо.

Хотя лично мне до сих пор хватало встроенных возможностей перла для реализации ООП, я даже в использовании Moo пока не чувствовал необходимости.

[@ksurent]

Не совсем. Или совсем нет. Mouse (как и Moose) — это уже готовые реализации объектных систем, в то время как mop — фреймворк для построения подобных систем. Если уж и было брать что–то из готового, то Class::MOP, но в начале статьи объясняется, почему этого делать не стали.
Речь не о том, чтобы просто разрешить разным системам «разговаривать» друг с другом через кучу костылей, а речь о том, чтобы задать стандарт (своего рода интерфейс) и базу для их написания.
Представим, что в версии перла 5.55 mop включили в стандартную библиотеку. Это будет означать, что в этот момент можно будет выкинуть Class::MOP и подобные модули, и переписать Moose, Mouse, и вообще все остальные Mo* модули (и не только) на основе mop. Это должно значительно упростить взаимодействие кода, построенного с помощью разных объектных систем.

[@vsespb]

В стандартной поставке нужен

Вообще на счёт core modules, майнтайнеры perl думают о них немного иначе, чем юзеры (может раньше было подругому).

Core modules — это что нужно для существования самого perl, для его деплоя, установки, тестов, для и соответственно, для работы установщика CPAN, документации POD.

Так что самую, самую расчудесную библиотеку не будут включать, чтобы юзерам было веселее.

[@powerman]

Ну, как раз эта формальная проблема решается тривиально — достаточно добавить пару классов в CPAN или perldoc использующих mop.

[@vsespb]

Я бы не сказал что это формальное правило, которое майнтайнеры хотят обойти, но сами не знают как.
Просто реально не хотят ничего пихать в ядро.

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

Так же майнтайнеры операционных систем постоянно давят на perl ( и на другие апстримы) и хотят уменьшить его размер (некоторые, например, RHEL пошли дальше, сами удалили модули из ядра, и perl в RHEL не настоящий, там нет многих core модулей, их нужно ставить отдельно). Видимо это связанно со всякими netinstall дистрибьютивами, которые влезают на огрызок cdrom и их хотят ещё больше уменьшить.

[@Alien]

Большое спасибо за статью, было интересно узнать об этом проекте, еще интереснее будет поиграть с ним.

[@SLY_G]

А как в классе-наследнике оперировать с атрибутами его родителя?

[@cruxacrux]

Через унаследованные аксессоры:

method set_x {
    $self->x(10)
}

[@vsespb]

Этот пост перевели на английский: blogs.perl.org/users/btyler/2013/10/a-metaobject-protocol-for-core-perl-5-translated-from-russian.html

[@powerman]

Там в комментариях отметился Stevan Little, скорректировав фразу насчёт публичных/приватных атрибутов — он пишет, что в mop атрибуты приватные, как и в Perl6. cruxacrux, исправьте это в статье, плз.

[@cruxacrux]

Спасибо, поправил.
Этот момент я обдумывал, но меня смутило то, что в mop для таких атрибутов автоматически создаётся аксессор, т.е. позволяет обратиться к ним за пределами класса, в то время как в Perl 6 такого нет. Сейчас взглянул на пример класса в Perl 6 и понял, что спутал аксессор и непосредственный доступ к переменной — это разные вещи. В mop пока нет публичных атрибутов.