Robert 'phaylon' Sedlacek: May 2009 Archives

As many of you will know by now, Moose comes with its own type system that you can use, extend and introspect. Since the types are handled in a global registry, you have to be concerned about namespaces like with every other perl package.

I started writing MooseX-Types with the objective of writing a tool that provides a solution to the namespace problem by simply enclosing type definitions in a library and turn the types into exports.

Since then, the community has put a lot of thought and effort into the idea and made it into much more. There are reusable type libraries on CPAN for DateTime, Path-Class, data structures, input/output, URIs, and the common extensions of the core types. You can also for some time now refer to imported types in MooseX-Method-Signatures.

With the recent rise of Devel-Declare, we have a lot more options for defining our interfaces. There is already thought and work put into developing nicer sugar for declaring type libraries, so I focused on sugar for importing the types that models nicely onto MooseX-Declare. This article is a summary if what I’ve come up with so far.

For quite some time now there have been appearances of a new type of declarative modules on CPAN. Some of these (but not all) are MooseX::Method::Signatures, giving you a method keyword with signatures and type validation; TryCatch which provides you with a modern and elegant way to catch exceptions; and MooseX::Declare, a whole extendable, declarative framework around the Moose ecosystem.

To many people who don’t have the time or the interest to live on the edge of advancements in the Perl community, this might seem like magic trickery, much like source filters. And because of this many people keep a safe distance from all these developments, like they rightfully do with source filters. You should never use something before you know how it works on a deep enough level for decision making. This is why I decided to write this post, and to show how all of this is made possible.

Those of you who are not regulars on irc.perl.org or don’t hang out in the #catalyst channel might not be aware of this, but the discussion, planning and chanting was going on for a while. With the recent rise of Devel::Declare this discussion has flamed up again.

There are many people thinking about how to design this, and even some implementations are already around. I’d like to use this article to discuss my own take on how a declarative Catalyst might look like.

When you build a web application with Catalyst, your controller will retrieve data from your model (or operate on it), prepare it, and put it in the stash so the view can access it. Your layout will be organized by templates that load more or less reusable subtemplates.

Reaction on the other hand comes shipped with its own UI system. In this post I will try to describe its components and how they interact.