Comments 37
Хм, вроде начинает нравиться, надо будет как-нибудь опробовать на чем-нибудь мелком.
Вижу пока один недостаток — отсутствие подсветки синтаксиса в редакторах.
Вижу пока один недостаток — отсутствие подсветки синтаксиса в редакторах.
Для Moose есть стандартный errorHandler? Хочу избежать засорения кода лишними обертками из eval BLOCK.
Должно получиться нечто похожее на:
my $game = Game->new or die Game->errstr;
Должно получиться нечто похожее на:
my $game = Game->new or die Game->errstr;
В «комплекте по-умолчанию» такого нет. Хотя вобщем-то и среди расширений я такого не видел.
Но реализовать такое вручную не сложно: вы можете вмешаться в работу стандартного конструктора используя ф-ю BUILD.
PS: код не проверял, писал сразу сюда
Но реализовать такое вручную не сложно: вы можете вмешаться в работу стандартного конструктора используя ф-ю 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: код не проверял, писал сразу сюда
Замечательно. Теперь понятно куда копать. Благодарю за BUILD.
«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
search.cpan.org/dist/Moose/lib/Moose/Cookbook/Basics/Recipe10.pod
Я тоже читал документацию. Что я должен из этого извлечь?
В примере ошибка. Он просто банально не сработает. Так как объект УЖЕ сконструирован.
Пример всего-лишь указывал, что можно посмотреть в сторону 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;
По ошибкам — сейчас активно используется модуль нашего британского коллеги TryCatch — search.cpan.org/~ash/TryCatch-1.001001/lib/TryCatch.pm
Хотелось бы еще добавить одну строчку
__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.»
__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.»
когда перл перестаёт быть перлом, и начинается изучение «нового языка»…
вообщем я против такого. если нужна вся полнота ООП — добро пожаловать в яву. а то что над перлом создаётся такая прослойка — это не рентабельно для бизнеса ни в качестве поддержки, ни в качестве расширения.
вообщем я против такого. если нужна вся полнота ООП — добро пожаловать в яву. а то что над перлом создаётся такая прослойка — это не рентабельно для бизнеса ни в качестве поддержки, ни в качестве расширения.
А люди вот думают (а главное и делают) по другому. В качестве примера вам — BBC Corp. У них внутри довольно активно используется перл, и сейчас его рефакторят с использованием Moose.
Тем более, что перл конечно же остается перлом. Вся его гибкость и свобода, которую он предоставляет разработчику, остается.
Тем более, что перл конечно же остается перлом. Вся его гибкость и свобода, которую он предоставляет разработчику, остается.
> если нужна вся полнота ООП — добро пожаловать в яву
«Полное» ООП в яве? Бред, там сроду не было полного ООП.
Полное ООП есть в Smalltalk, Newsqueak, etc.
«Полное» ООП в яве? Бред, там сроду не было полного ООП.
Полное ООП есть в Smalltalk, Newsqueak, etc.
Тогда ваш язык — PHP. Перл дает богатое пространство выбора, которым не всякий способен воспользоваться. Но Перл — язык для лушчих :)
О! хорошая статья, спасибо. Modern Perl5 и Perl6 внешне уже похожи на диалекты одного и того же языка, в отличии от просто Perl5 и Perl6 :)
По поводу augment+inner. А зачем собсно такие сложности? Что мешает сделать это на обычном ООП, без введения «синтаксического мусора» (и сопутствующего обслуживающего кода в Moose), просто и понятно?
Я всячески приветствую модули, которые упрощают разработку, но по-моему авторы этих модулей свернули по пути куда-то не туда. Да, объектная модель перла, кхм, специфична. Но она работает и у нее даже есть свои прелести. Попытки довести ее до классической, в том числе синтаксическими подсластителями, наводят на мысли о том, что авторы на самом деле выбрали не тот язык программирования. Можно, конечно, поставить на жигули кузов от мерседеса, но в результате мы получим не мерседес, а жигули с кузовом от мерседеса. По-моему так. Но если Вам нравится, то пожалуйста :)
sub create_request { # это наследуется
my $self = shift;
my $xml = $self->_get_request_xml;
$xml->appendChild(....);
....
}
sub _getRequest_xml { # а это переопределяется в дочернем классе
.....
return $xml
}
Я всячески приветствую модули, которые упрощают разработку, но по-моему авторы этих модулей свернули по пути куда-то не туда. Да, объектная модель перла, кхм, специфична. Но она работает и у нее даже есть свои прелести. Попытки довести ее до классической, в том числе синтаксическими подсластителями, наводят на мысли о том, что авторы на самом деле выбрали не тот язык программирования. Можно, конечно, поставить на жигули кузов от мерседеса, но в результате мы получим не мерседес, а жигули с кузовом от мерседеса. По-моему так. Но если Вам нравится, то пожалуйста :)
Я привел недостаточно сложный пример. augment+inner имеет неограниченную глубину вложенности. Можно аугментировать уже аугментированные методы (естественно не в одном классе, а в дочерних). А простое переопределение метода скорее всего приведет к дублированию кода. Но, да, в целом я согласен, что это «сложность» и не стоит ей злоупотреблять.
На мой взгляд, это просто прослойка, которая поможет многим справиться с Perl6. Не хотите? Да пожалуйста, не надо. Можно писать очень стройные вещи используя и просто Moose. Но мне нравится, да)
На мой взгляд, это просто прослойка, которая поможет многим справиться с Perl6. Не хотите? Да пожалуйста, не надо. Можно писать очень стройные вещи используя и просто Moose. Но мне нравится, да)
Пока не вижу, как можно получить дублирование кода даже для сложных случаев. Вроде все решается по той же схеме, нет?
Мне кажется, Perl6 это все-таки другой язык, имеющий мало общего с Perl5 (кроме названия), и справляться с ним имеет смысл именно исходя из этих оснований. Не будете же Вы переопределять оператор «точка», чтобы получить в перле жаба-синтаксис для вызова методов и таким образом «справиться с Java» :)
Мне кажется, Perl6 это все-таки другой язык, имеющий мало общего с Perl5 (кроме названия), и справляться с ним имеет смысл именно исходя из этих оснований. Не будете же Вы переопределять оператор «точка», чтобы получить в перле жаба-синтаксис для вызова методов и таким образом «справиться с Java» :)
Пример получается довольно надуманный, но к сожалению в голову больше ничего не пришло: класс-«внук» не сможет сохранить часть функционала от дочернего класса первого уровня. Вы можете только целиком переопределить метод. А выделять для каждого нового уровня наследования отдельный метод — не есть хорошо. Хотя наличие таких проблем возможно является символом того, что в проектировании имеются недостатки.
Не поймите меня неправильно, я ведь не агитирую использование этого приема. Я рассказал, что так можно делать, и что мне удалось найти место, где (на мой взгляд) это оказалось уместно.
Сравнение с джавой, имхо, некорректно. Да, Perl6 сильно отличается от 5, но все-таки он не является полностью новым языком. Как ни крути, а я уверен, что многие мигруют на 6 после релиза. Даже разработчики агитируют к этому. Поэтому делать прослойку из Perl5 в Perl6 имеет смысл, а вот из Perl в Java — нет.
Когда я увидел первые наброски синтаксиса Perl6 (особенно гипер-операторы), я был уверен, что я не буду его использовать. Сейчас я уже не так уверен. Конечно, legacy-код никуда не денется, но для новых проектов я возможно буду использовать 6 версию.
Не поймите меня неправильно, я ведь не агитирую использование этого приема. Я рассказал, что так можно делать, и что мне удалось найти место, где (на мой взгляд) это оказалось уместно.
Сравнение с джавой, имхо, некорректно. Да, Perl6 сильно отличается от 5, но все-таки он не является полностью новым языком. Как ни крути, а я уверен, что многие мигруют на 6 после релиза. Даже разработчики агитируют к этому. Поэтому делать прослойку из Perl5 в Perl6 имеет смысл, а вот из Perl в Java — нет.
Когда я увидел первые наброски синтаксиса Perl6 (особенно гипер-операторы), я был уверен, что я не буду его использовать. Сейчас я уже не так уверен. Конечно, legacy-код никуда не денется, но для новых проектов я возможно буду использовать 6 версию.
Спасибо, пример понятен. Во многих случаях эта проблема действительно отпадет на этапе проектирования, но не всегда. А что касается 6ки, мне проще считать что это совсем отдельный язык, нежели продолжение 5й ветки. Уж больно велики различия. Вообще конечно поскорее бы они уже ее выпустили, ждать устали все :)
Перл это язык, на котором можно легко написать Перл 6 и Перл 7.
А для тех старпёров, кто боится вылезти за Perl::Core на perl.org давно построили отдельное кладбище.
А для тех старпёров, кто боится вылезти за Perl::Core на perl.org давно построили отдельное кладбище.
Кстати, что супер круто- так это то, что таким образом выкристаллизовываются оптимальные практики программирования. И нет никаких правил законов и ограничений — можно построить хоть марсоход. А вот Перл6 может получиться удачным, а может и нет — и если Perl-Core будет неудачным, то это поставит крест на Перл6. Но Перл 6 и Муз очень положительно друг на друга влияют, так что за ближайший год Муз может определить дальнейшее развитие Перл 6 и его базовое наполнение.
А по поводу накладных расходов- на них больше потрачено энергии на разговоры в ваттах, чем ватт электричества на эти самые накладные раходы.
А по поводу накладных расходов- на них больше потрачено энергии на разговоры в ваттах, чем ватт электричества на эти самые накладные раходы.
Перл действительно мегаязык, хоть и уже 4 года на нем не пишу (за исключением консольных скриптов).
Кто-нибудь знает, как технически делается подобное? Пришел в шок, когда это увидел:
class Business::Qiwi::Balance extends Business::Qiwi::Request
Каким образом так расширяемся синтаксис?
Кто-нибудь знает, как технически делается подобное? Пришел в шок, когда это увидел:
class Business::Qiwi::Balance extends Business::Qiwi::Request
Каким образом так расширяемся синтаксис?
По большей части это реализовано с помощью модуля Devel::Declare. А вот уж как он работает, я подробно объяснить не могу, к сожалению. Часть его написана с помощью XS. Короче «hairy black magic».
А вот и более подробное объяснение: www.catalyzed.org/2009/05/dawn-of-a-new-age-in-perl-how-develdeclare-extends-perls-syntax.html
Пиши еще!
Sign up to leave a comment.
Moose(X). Продолжение