moose

What is the best way to handle a failure in a builder method? For example: package MyObj; use Moose; use IO::File; has => 'file_name' ( is => 'ro', isa => 'Str', required =>1 ); has => 'file_handle' ( is => 'ro', isa => 'IO::File', lazy_build => 1 ); sub _build_file_handle { my $self = shift; my $fh = IO::File->new( $self->file_name, '<' ); return $fh; } If the _build_file_handle fails to get a handle, the builder will return undef , which fails the type constraint. I could use a union in the file_handle type constraint, so that it will accept an undef as a valid value. But then, the predicate

I've started a conversion of a project to Moose and the first thing I noticed was that my critic/tidy tests go to hell. Moose, Tidy and Critic don't seem to like each other as much as they used to. Are there docs anywhere on how to make critic/tidy be more appreciative of the Moose dialect? What do most Moose users do? Relax/ditch critic for the more heavy Moose modules? Custom policies? Have you seen Perl::Critic::Moose ? Both of them can be configured into detail. I have no idea why perltidy wouldn't like it, it has nothing to do with it . Perltidy only governs style. You can change the

I've been playing around with Moose, getting a feel for it. I'd like an example of pure virtual functions like in C++ but in Moose parlance (specifically in a C++-looking way). I know that even with Moose imposing a stricter model than normal Perl, there's still more than one way to do what I'm asking (via method modifiers or SUPER:: calls). That is why I'm asking specifically for an implementation resembling C++ as much as possible. As for the "why?" of this restriction? Mostly curiosity, but also planning to port some C++ code to Perl with Moose in a way that C++-centric people could mostly

Moose is a fantastic object framework. The trouble is that, taken together with its dependencies, it's very big. Our profiling indicates that on our platform, simply loading Moose will incur a 5-6 second overhead on non-persistent CGI application scripts. That's just not acceptable for these one-off applications. By contrast, when we're using a persistent process system (such as FCGI), this startup overhead is eliminated (or rather, only incurred once), and all is well. The problem we have is that we can't guarantee that all of our code will always run under a persistent process. We

From the current version (0.98) of the Moose::Manual::MooseX are the lines: We have high hopes for the future of MooseX::Method::Signatures and MooseX::Declare . However, these modules, while used regularly in production by some of the more insane members of the community, are still marked alpha just in case backwards incompatible changes need to be made. I noticed that for MooseX::Method::Signatures the change log for September 2009 mentions the removal of the " scary ALPHA disclaimer ". So, are these still "alpha"? Would I still be considered one of the "more insane" to use them? I'd say

Closed . This question is opinion-based. It is not currently accepting answers. Learn more . Want to improve this question? Update the question so it can be answered with facts and citations by editing this post . I'm still relatively new to Perl Programming, but I know how Perl 5 OO basically works. However, I have never created any project with Perl 5 OO, so I'm quite sure I will run into many pitfalls. Recently I discovered the hype about the Moose module. I checked out some documentation on CPAN and I found it to be quite interesting and helping me as a developer a lot. Additionally, it

There's a lot of buzz about MooseX::Method::Signatures and even before that, modules such as Params::Validate that are designed to type check every argument to methods or functions. I'm considering using the former for all my future Perl code, both personal and at my place of work. But I'm not sure if it's worth the effort. I'm thinking of all the Perl code I've seen (and written) before that performs no such checking. I very rarely see a module do this: my ($a, $b) = @_; defined $a or croak '$a must be defined!'; !ref $a or croak '$a must be a scalar!"; ... @_ == 2 or croak "Too many