Moose Archives

Keeping Your Valuables Under Lock and Key

Consider the following fairly simple class, which creates a lookup object for month names:

package Local::MonthList { use experimental ="color:#333;backgr…

RFC: new API for Type::Params

Firstly, I'm not planning on breaking compatibility with Type::Params. The new API would live under a different namespace, such as Type::Params2.

The API for Type::Params is currently:

use feature 'state';
use Type::Params qw( compile compile_named_oo );
use Types::Standard -types;

sub function_with_positional_parameters {
  state $check = compile( ArrayRef, Int, Int );
  my ( $list, $start, $end ) = $check->( @_ );

  my @slice = @{$list}[ $start .. $end ];
  return \@slice;
}

sub function_with_na…

Mite: an OO compiler for Perl

Moose is great, but it does introduce a slight performance hit to your code. In the more than 15 years since it was first released, hardware improvements have made this less of a problem than it once was. Even so, if performance is a concern for your project, Moose might not be what you want. It also has a fairly big collection of non-core dependencies.

Moo is a lighter weight version, minus with meta-object protocol, but supporting nearly all of Moose's other features. It loads faster, sometimes runs faster, and has fewer dependencies. (And most of the dependencies it does have are just modules which used to be part of Moo but were split out into separate distributions.)

But what if you could have fast Moose-like object-oriented code without the dependencies?

In 2013, Michael Schwern started work on Mite to do just that. It was abandoned in 2014, but I've taken it over and expanded the feature set to roughly equivalent to Moo.

Mite is an object-oriented programming compiler for Perl. It allows you to write familiar Moose-like object-oriented code, then compile that into plain Perl with zero non-core dependencies. Your compiled code does not even have a dependency on Mite itself!

Announcing Zydeco

Technically, I already announced it, but now I've renamed it. MooX::Pression is now called Zydeco.

Moops had a memorable name, and I think the naming really helped it gain a following. MooX::Pression was just meh. So now it's Zydeco. Zydeco is a fun word and pretty short to type. It's a musical genre that blends jazz, blues, and Louisiana French Creole, and it just seemed like a good fit for a module that takes what I feel are some of the coolest features of Perl programming, and blen…

MooX::Pression — now much faster

The test suite for MooX::Pression used to run in 79 seconds on my laptop. Now it's at 10 seconds.

And no, I didn't cut out any tests — I switched from using Keyword::Declare to a combination of Keyword::Simple and PPR. (Keyword::Declare is a wrapper around Keyword::Simple and PPR, but I found out by using them directly, I could massively improve compile-time speed.)

MooX::Pression allows you to build classes and roles with multimethods, types, method signatures, and sweet, sweet, sugary syntax…

Announcing MooX::Pression

Kind of like Moops but with less hacky parsing.

Exploring Type::Tiny Part 7: Creating a Type Library with Type::Library

Type::Tiny is probably best known as a way of having Moose-like type constraints in Moo, but it can be used for so much more. This is the seventh in a series of posts showing other things you can use Type::Tiny for. This article along with the earlier ones in the series can be found on my blog and in the Cool Uses for Perl section of PerlMonks.

For small projects, the type constraints in Types::Standard and other CPAN type libraries are probably enough to satisfy your needs. You can do things like:

   use Types::Common::Numeric qw(PositiveInt);
   
   has user_id => (
      is   => 'ro',
      isa  => PositiveInt,
   );

However for larger apps, say you need to check user identity numbers in an handful of places throughout your code and you use PositiveInt everywhere, then if you ever feel the need to change the constraint for them, you'll need to hunt through your code to look for every use of PositiveInt, make sure it's not being used for some other reason (like to check an age or a counter), and update it.

So it is helpful to make your own application-specific type library. You can define your own UserId type constraint, and use that everywhere. If the format of your identifiers ever changes, you only need to change the definition of the type constraint.

Exploring Type::Tiny Part 2: Using Type::Tiny with Moose

Type::Tiny is probably best known as a way of having Moose-like type constraints in Moo, but it can be used for so much more. This is the second in a series of posts showing other things you can use Type::Tiny for. You can refer back to part 1.

Type::Tiny is often used in Moo classes and roles as a drop-in replacement for Moose's built-in type system. But the original reason I wrote it was as a response to the growing number of MooseX::Types and MouseX::Types modules on CPAN. I thought "wouldn't it be good if you could write a type library once, and use it for Moose, Mouse, and maybe even Moo?" In the very early version, you needed to import types like this:

   use Type::Standard -moose, qw(Int);
   use Type::Standard -mouse, qw(Int);
   use Type::Standard -moo,   qw(Int);

Specifying which object system you were using allowed the type library to export different blessed type constraint objects for different object frameworks. Eventually this need was eliminated by having Type::Tiny's objects better mock the Moose and Mouse native APIs, so the frameworks didn't even notice you weren't using their built-in type constraints.

(While no longer documented, the -moose, etc import flags still work in all Type::Library-based type libraries.)

Anyway, so now you know Type::Tiny types can work with Moose, what are the reasons to use them over Moose's built-in type constraints?

What is a Bool?

Perl allows pretty much any value to be evaluated in a boolean context:

if ($something) {
   ...
}

No matter what $something is, it will safely evaluate to either true or false. (With the exceptions of a few edge cases like blessed objects which are overloaded to throw an error when evaluated as booleans.)

So when a Moose class does something like this, what does it mean?

has something => (
   is  => 'ro',
   isa => 'Bool',
);

Perils of Plugins

Plugin-based architectures can be a bad idea.

Not always. In user-facing applications, where the list of installed and enabled plugins is clear, then plugins are often a good thing. This article is concerned not with end-user facing applications, but with libraries. Libraries that allow their functionality to be extended through plugins. In particular, libraries that automatically detect and load all installed plugins.

Plugins aren't always obviously plugins. In this article, I'm defining a plugin as a software module that adds additional functionality or modifies the external…

About Toby Inkster

user-pic I'm tobyink on CPAN, IRC and PerlMonks.