Moose(X). Продолжение

[@spleenjack]

Хм, вроде начинает нравиться, надо будет как-нибудь опробовать на чем-нибудь мелком.
Вижу пока один недостаток — отсутствие подсветки синтаксиса в редакторах.

[@ksurent]

vim: www.vim.org/scripts/script.php?script_id=2526
emacs: github.com/jrockway/cperl-mode/tree/master

[@JIP]

Для Moose есть стандартный errorHandler? Хочу избежать засорения кода лишними обертками из eval BLOCK.

Должно получиться нечто похожее на:
my $game = Game->new or die Game->errstr;

[@ksurent]

В «комплекте по-умолчанию» такого нет. Хотя вобщем-то и среди расширений я такого не видел.
Но реализовать такое вручную не сложно: вы можете вмешаться в работу стандартного конструктора используя ф-ю BUILD.
package Foo;
use Moose;

has errstr => ( is=>'ro', isa => 'Str', lazy => 1, ); # правильнее будет вынести это в роль, но для сокращения кода оставлю так

sub BUILD {
my $self = shift;
my $obj = eval { $self->SUPER::BUILD(@_) };
$self->errstr($@) if $@;

$obj
}


PS: код не проверял, писал сразу сюда

[@JIP]

Замечательно. Теперь понятно куда копать. Благодарю за BUILD.

[@zukoff]

«The BUILD method is called after the object is constructed, but before it is returned to the caller. The BUILD method provides an opportunity to check the object state as a whole. This is a good place to put logic that cannot be expressed as a type constraint on a single attribute.»

search.cpan.org/dist/Moose/lib/Moose/Cookbook/Basics/Recipe10.pod

[@ksurent]

Я тоже читал документацию. Что я должен из этого извлечь?

[@zukoff]

В примере ошибка. Он просто банально не сработает. Так как объект УЖЕ сконструирован.

[@ksurent]

Пример всего-лишь указывал, что можно посмотреть в сторону BUILD. Код я написал, что называется «от балды». С SUPER, пожалуй, получилось и правда не очень удачно, т.к. кажется как-будто я пытаюсь вернуть другой объект. Можно чуть подправить и сделать вот так (в итоге получается почти то же самое):

sub BUILD {
  my $self = shift;
  # some checks
  unless($success) {
     $self->errstr('bla')
  }
}
# ...
my $foo = Foo->new;
die $foo->errstr if $foo->has_errstr;

[@zukoff]

search.cpan.org/dist/Moose/lib/Moose/Manual/FAQ.pod#How_do_I_write_custom_constructors_with_Moose?

[@zukoff]

По ошибкам — сейчас активно используется модуль нашего британского коллеги TryCatch — search.cpan.org/~ash/TryCatch-1.001001/lib/TryCatch.pm

[@khizhaster]

Хотелось бы еще добавить одну строчку
__PACKAGE__->meta->make_immutable;

search.cpan.org/~drolsky/Moose-0.79/lib/Moose/Cookbook/Basics/Recipe7.pod

В большинстве случаев немного ускоряет работу. Как пишут сами девелоперы:
«We strongly recommend you make your classes immutable. It makes your code much faster, with a small compile-time cost. This will be especially noticeable when creating many object.»

[@ksurent]

Еще можно делать no Moose перед этим, что в скриптах использующих ваши классы не был доступен синактический сахар. Вот только к «фишкам» это сложно отнести.

ЗЫ: кстати, при использовании MooseX::Declare это делается автоматически. Об этом написано в конце п. 2.1

[@tr0nd]

когда перл перестаёт быть перлом, и начинается изучение «нового языка»…
вообщем я против такого. если нужна вся полнота ООП — добро пожаловать в яву. а то что над перлом создаётся такая прослойка — это не рентабельно для бизнеса ни в качестве поддержки, ни в качестве расширения.

[@ksurent]

А люди вот думают (а главное и делают) по другому. В качестве примера вам — BBC Corp. У них внутри довольно активно используется перл, и сейчас его рефакторят с использованием Moose.
Тем более, что перл конечно же остается перлом. Вся его гибкость и свобода, которую он предоставляет разработчику, остается.

[@chiaroscuro]

> если нужна вся полнота ООП — добро пожаловать в яву

«Полное» ООП в яве? Бред, там сроду не было полного ООП.

Полное ООП есть в Smalltalk, Newsqueak, etc.

[@tr0nd]

я говорил про нормальные языки, а не про академических заморышей…

[@chiaroscuro]

Что, Smalltalk-то академический? :)

Newsqueak — да, академический, но его потомки — нет.

[@santeri]

тут был пост, что перл-программисты самые счастливые :)

[@zukoff]

Тогда ваш язык — PHP. Перл дает богатое пространство выбора, которым не всякий способен воспользоваться. Но Перл — язык для лушчих :)

[@tr0nd]

мой язык — перл. и при этом я рад, что я с вами не работаю над одним проектом. в промышленном программировании вот это «богатое пространство выбора» в итоге приводит к тому, что на определённом этапе быстроразвивающегося проекта поддержка превращается в непрекращающийся аврал.

[@ihrd]

О! хорошая статья, спасибо. Modern Perl5 и Perl6 внешне уже похожи на диалекты одного и того же языка, в отличии от просто Perl5 и Perl6 :)

[@Bambr]

По поводу augment+inner. А зачем собсно такие сложности? Что мешает сделать это на обычном ООП, без введения «синтаксического мусора» (и сопутствующего обслуживающего кода в Moose), просто и понятно?

sub create_request { # это наследуется
my $self = shift;
my $xml = $self->_get_request_xml;
$xml->appendChild(....);
....
}

sub _getRequest_xml { # а это переопределяется в дочернем классе
.....
return $xml
}


Я всячески приветствую модули, которые упрощают разработку, но по-моему авторы этих модулей свернули по пути куда-то не туда. Да, объектная модель перла, кхм, специфична. Но она работает и у нее даже есть свои прелести. Попытки довести ее до классической, в том числе синтаксическими подсластителями, наводят на мысли о том, что авторы на самом деле выбрали не тот язык программирования. Можно, конечно, поставить на жигули кузов от мерседеса, но в результате мы получим не мерседес, а жигули с кузовом от мерседеса. По-моему так. Но если Вам нравится, то пожалуйста :)

[@ksurent]

Я привел недостаточно сложный пример. augment+inner имеет неограниченную глубину вложенности. Можно аугментировать уже аугментированные методы (естественно не в одном классе, а в дочерних). А простое переопределение метода скорее всего приведет к дублированию кода. Но, да, в целом я согласен, что это «сложность» и не стоит ей злоупотреблять.

На мой взгляд, это просто прослойка, которая поможет многим справиться с Perl6. Не хотите? Да пожалуйста, не надо. Можно писать очень стройные вещи используя и просто Moose. Но мне нравится, да)

[@Bambr]

Пока не вижу, как можно получить дублирование кода даже для сложных случаев. Вроде все решается по той же схеме, нет?

Мне кажется, Perl6 это все-таки другой язык, имеющий мало общего с Perl5 (кроме названия), и справляться с ним имеет смысл именно исходя из этих оснований. Не будете же Вы переопределять оператор «точка», чтобы получить в перле жаба-синтаксис для вызова методов и таким образом «справиться с Java» :)

[@ksurent]

Пример получается довольно надуманный, но к сожалению в голову больше ничего не пришло: класс-«внук» не сможет сохранить часть функционала от дочернего класса первого уровня. Вы можете только целиком переопределить метод. А выделять для каждого нового уровня наследования отдельный метод — не есть хорошо. Хотя наличие таких проблем возможно является символом того, что в проектировании имеются недостатки.
Не поймите меня неправильно, я ведь не агитирую использование этого приема. Я рассказал, что так можно делать, и что мне удалось найти место, где (на мой взгляд) это оказалось уместно.

Сравнение с джавой, имхо, некорректно. Да, Perl6 сильно отличается от 5, но все-таки он не является полностью новым языком. Как ни крути, а я уверен, что многие мигруют на 6 после релиза. Даже разработчики агитируют к этому. Поэтому делать прослойку из Perl5 в Perl6 имеет смысл, а вот из Perl в Java — нет.
Когда я увидел первые наброски синтаксиса Perl6 (особенно гипер-операторы), я был уверен, что я не буду его использовать. Сейчас я уже не так уверен. Конечно, legacy-код никуда не денется, но для новых проектов я возможно буду использовать 6 версию.

[@Bambr]

Спасибо, пример понятен. Во многих случаях эта проблема действительно отпадет на этапе проектирования, но не всегда. А что касается 6ки, мне проще считать что это совсем отдельный язык, нежели продолжение 5й ветки. Уж больно велики различия. Вообще конечно поскорее бы они уже ее выпустили, ждать устали все :)

[@zukoff]

Перл это язык, на котором можно легко написать Перл 6 и Перл 7.
А для тех старпёров, кто боится вылезти за Perl::Core на perl.org давно построили отдельное кладбище.

[@Bambr]

Написать-то легко. Вопрос в том, зачем? Чтоб былО? Или чтоб быстрее работало?

[@zukoff]

Ответ на свой вопрос попробуйте найти самостоятельно :)) Это как разговаривать слепому с глухим.

[@zukoff]

Кстати, что супер круто- так это то, что таким образом выкристаллизовываются оптимальные практики программирования. И нет никаких правил законов и ограничений — можно построить хоть марсоход. А вот Перл6 может получиться удачным, а может и нет — и если Perl-Core будет неудачным, то это поставит крест на Перл6. Но Перл 6 и Муз очень положительно друг на друга влияют, так что за ближайший год Муз может определить дальнейшее развитие Перл 6 и его базовое наполнение.

А по поводу накладных расходов- на них больше потрачено энергии на разговоры в ваттах, чем ватт электричества на эти самые накладные раходы.

[@Bonch]

Перл действительно мегаязык, хоть и уже 4 года на нем не пишу (за исключением консольных скриптов).

Кто-нибудь знает, как технически делается подобное? Пришел в шок, когда это увидел:

class Business::Qiwi::Balance extends Business::Qiwi::Request

Каким образом так расширяемся синтаксис?

[@ksurent]

По большей части это реализовано с помощью модуля Devel::Declare. А вот уж как он работает, я подробно объяснить не могу, к сожалению. Часть его написана с помощью XS. Короче «hairy black magic».

[@ksurent]

А вот и более подробное объяснение: www.catalyzed.org/2009/05/dawn-of-a-new-age-in-perl-how-develdeclare-extends-perls-syntax.html

[@zukoff]

Пиши еще!