#modern_perl

[meettya-blog-blog]

Про accessor-ы

Недавно нашел забавный модуль App::Benchmark::Accessors.

Узнал, что есть больше дюжины варианта сотворить акцессоры. Померился со своим Object::Botox.

Ну, с одной стороны – он тормоз. С другой стороны – во-первых оно делает ro-поля, во вторых корректно работает с наследованием, в том числе и множественным.

А значит вполне покатит для прототипирования, бо если уж что-то упрется в скорость создания объектов – ну, тогда и будет повод размышлять о более производительной модели.

Для себя сформулировал мыслю так –

bad working beta by a factor of ten better of pretty shining non-working alpha

эээ.. ну, “лучшее – враг хорошего”.

[meettya-blog-blog]

wantarray or die; принуждаем проверять ошибки без exception

Много раз пробовал использовать exception в разных вариантах и каждый раз путаюсь с ними, на каком уровне ошибки еще приемлимо а на каком уже нет.

Умные книжки пишут, что исключеие - это реально исключительная ситуация, когда ошибка невосстановима и ее нельзя проигнорировать, т.е. это ошибка кода.

Значит использовать исключения при валидации параметров - проверке по сути логики - это как прикуривать от динамитной шашки. Можно, но стремно.

Сегодня закралась интересная мысля - а почему собственно нельзя все методы, которые МОГУТ вернуть ошибку, писать с проверкой обязательного спискового контекства вызова?

wantarray or die;

Ну или croak :)

#!/usr/bin/env perl   use v5.10; use warnings;   use Carp qw( croak );   my $wantarr_text = 'list context call ONLY, second value for error status';   sub my_capricious_sub{         my $data_in = shift;                         # I think it is good practice         wantarray or croak $wantarr_text;                 if ( $data_in ne 'other_data' )         {                           return undef, 'input mismatch';                 }                                 return 1;         }           my $i_dont_care_about_errors = my_capricious_sub('some_data');

  Рабочий не рабочий пример http://ideone.com/41wbk.

>