Comments 17
Звучит настолько круто, что даже тяжело поверить. Особенно если у них получится встроить этот функционал без потери обратной совместимости.
+2
На самом деле это звучит как картинка про «15 несовместимых стандартов плюс ещё один новый». Но если им удастся этот новый модуль засунуть в ядро, добиться чтобы он был действительно лёгким и быстрым (после реализации всех необходимых фич), и сагитировать народ активно на него переходить с Moose и Moo — тогда да, будет неплохо.
Хотя лично мне до сих пор хватало встроенных возможностей перла для реализации ООП, я даже в использовании Moo пока не чувствовал необходимости.
Хотя лично мне до сих пор хватало встроенных возможностей перла для реализации ООП, я даже в использовании Moo пока не чувствовал необходимости.
0
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. Это должно значительно упростить взаимодействие кода, построенного с помощью разных объектных систем.
+3
UFO just landed and posted this here
В стандартной поставке нужен
Вообще на счёт core modules, майнтайнеры perl думают о них немного иначе, чем юзеры (может раньше было подругому).
Core modules — это что нужно для существования самого perl, для его деплоя, установки, тестов, для и соответственно, для работы установщика CPAN, документации POD.
Так что самую, самую расчудесную библиотеку не будут включать, чтобы юзерам было веселее.
0
Ну, как раз эта формальная проблема решается тривиально — достаточно добавить пару классов в CPAN или perldoc использующих mop.
0
Я бы не сказал что это формальное правило, которое майнтайнеры хотят обойти, но сами не знают как.
Просто реально не хотят ничего пихать в ядро.
К тому же, всё что в ядре — должно использовать только модули в ядре, авторы некоторых модулей не хотят чтобы их модули добавляли в ядро и лишали их сводобы.
Так же майнтайнеры операционных систем постоянно давят на perl ( и на другие апстримы) и хотят уменьшить его размер (некоторые, например, RHEL пошли дальше, сами удалили модули из ядра, и perl в RHEL не настоящий, там нет многих core модулей, их нужно ставить отдельно). Видимо это связанно со всякими netinstall дистрибьютивами, которые влезают на огрызок cdrom и их хотят ещё больше уменьшить.
Просто реально не хотят ничего пихать в ядро.
К тому же, всё что в ядре — должно использовать только модули в ядре, авторы некоторых модулей не хотят чтобы их модули добавляли в ядро и лишали их сводобы.
Так же майнтайнеры операционных систем постоянно давят на perl ( и на другие апстримы) и хотят уменьшить его размер (некоторые, например, RHEL пошли дальше, сами удалили модули из ядра, и perl в RHEL не настоящий, там нет многих core модулей, их нужно ставить отдельно). Видимо это связанно со всякими netinstall дистрибьютивами, которые влезают на огрызок cdrom и их хотят ещё больше уменьшить.
0
UFO just landed and posted this here
Большое спасибо за статью, было интересно узнать об этом проекте, еще интереснее будет поиграть с ним.
0
А как в классе-наследнике оперировать с атрибутами его родителя?
0
Этот пост перевели на английский: blogs.perl.org/users/btyler/2013/10/a-metaobject-protocol-for-core-perl-5-translated-from-russian.html
0
Спасибо, поправил.
Этот момент я обдумывал, но меня смутило то, что в mop для таких атрибутов автоматически создаётся аксессор, т.е. позволяет обратиться к ним за пределами класса, в то время как в Perl 6 такого нет. Сейчас взглянул на пример класса в Perl 6 и понял, что спутал аксессор и непосредственный доступ к переменной — это разные вещи. В mop пока нет публичных атрибутов.
Этот момент я обдумывал, но меня смутило то, что в mop для таких атрибутов автоматически создаётся аксессор, т.е. позволяет обратиться к ним за пределами класса, в то время как в Perl 6 такого нет. Сейчас взглянул на пример класса в Perl 6 и понял, что спутал аксессор и непосредственный доступ к переменной — это разные вещи. В mop пока нет публичных атрибутов.
0
Sign up to leave a comment.
Articles
Change theme settings
Metaobject Protocol для базового Perl 5