Moo Archives

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!

Mood Lighting

The lighting in my bedroom uses Philips Hue bulbs — specifically, the coloured ones. Last night, I decided it would be nice to set the three lights in my bedroom to cycle slowly through a set of warm colours using a script.

I didn't want harsh transitions from one colour to the next, but for the lighting to fade from one colour to the next in a smooth gradient. Also, I didn't want the three bulbs to all be the exact same colour, but wanted each bulb to be at different stage in the cycle, like they're "chasing" each other through the colours.

So I whipped up a quick script. It requires the command-line tool hueadm to be installed and set up before we start. You can run hueadm lights to get a list of available lights, and in particular, their ID numbers.


Today I released Zydeco::Lite, a re-implementation of Zydeco but just using standard Perl syntax. So for example, class { ... } becomes class(sub { ...});.

This has the advantage of much faster compile time, similar run time speed, fewer dependencies, and compatibility with older versions of Perl before the keyword API was introduced. Of course, in some circumstances these aren't important concerns, so the nicer syntax of the full Zydeco will be preferred.

Zydeco and Zydeco::Lite are both based on MooX::Press which itself is based on Moo, Type::Tiny, and other modules. I've taken the synopsis example from the Zydeco documentation and rewritten it using the different layers of abstraction.

Web Scraping with Zydeco

So I like to keep local copies of my blog posts as Atom entries, but noticed yesterday that I had a few gaps in my collection. The Atom feeds offered by only have the most recent articles though, so I decided to write a quick script to scrape the posts. Luckily, I managed to get a table containing the URLs for each post I needed, so I didn't need to bother with following links to find the pages; I just needed to grab the content from them.

I thought some people might find the code interesting especially for its use of lazy attributes. This is one of those "it only needs to be used once, so making the code maintainable isn't important" kinds of projects, do bear that in mind. I've cleaned up the whitespace and added comments for this blog post, but other than that, it's just a quickly hacked together script.

Let Mom Help You With Object-Oriented Programming

Mom is a shortcut for creating Moo classes (and roles). It allows you to define a Moo class with the brevity of Class::Tiny. (In fact, Mom is even briefer.)

A simple example:

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.

Announcing MooX::Press

MooX::Press is a quick way of building a bunch of Moo roles and classes in one use statement.

The most basic example would be:

  package MyApp {
    use MooX::Press class => ['Foo', 'Bar'];
  my $thing1 = MyApp::Foo->new();
  my $thing2 = MyApp->new_foo();   # alternative constructor

But do-nothing classes with a constructor and nothing else aren't very exciting. Let's define a class with some subclasses which have attributes and roles and methods and stuff.

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.

About Toby Inkster

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