A typical usage might be:

        package Person;
        use Moose;
        use Types::Standard -types;
        
        has name => (is => "ro", isa => Str);
        has age  => (is => "ro", isa => Int);

But why stop there? Type constraints can also be useful for other purposes such as unit testing (e.g. check your function returns an Int) and validation. It's validation we'll look at today; specifically validating sub parameters.

Let's take a look at a simple function which takes a hash, and returns a copy of that hash, but adding a number to certain keys.

        sub hash_add {
                my ($number, $hash, $keys) = @_;
                my %clone = %$hash;
                $clone{$_} += $number for @$keys;
                return \%clone;
        }
        
        my $r = hash_add(7, { foo => 1, bar => 2, baz => 3 }, [qw/foo bar/]);
        ## => { foo => 8, bar => 9, baz => 3 }

Why would you want a function like this? I admit it's somewhat contrived, but it includes three different types (a number, a hashref and an arrayref), so is a good illustration of the principles involved.

Here's how you'd add parameter validation using the venerable Params::Validate:

        use Params::Validate qw(:all);
        use Scalar::Util qw(looks_like_number);
        
        sub hash_add {
                my ($number, $hash, $keys) = validate_pos(@_,
                        {
                                type      => SCALAR,
                                callbacks => { numeric => sub { looks_like_number($_[0]) } },
                        },
                        { type => HASHREF },
                        { type => ARRAYREF },
                );
                ...;
        }

Using Type::Params which comes bundled with Type::Tiny is somewhat more elegant for this simple case (which is not to say that it is always so!):

        use Type::Params qw(compile);
        use Types::Standard -types;
        
        sub hash_add {
                state $check = compile(Num, HashRef, ArrayRef);
                my ($number, $hash, $keys) = $check->(@_);
                ...;
        }

But surely this elegance comes at some cost? After all; Params::Validate is fast! It has an XS backend that blows the socks off many of its rivals (Data::Validator, etc).

Well, you'd be wrong! According to my benchmarks, Type::Params is more than twice as fast as Params::Validate's XS backend. (And more than six times as fast as Params::Validate's pure Perl backend.) Don't believe me? Here is my benchmark script.

In fact, Type::Params is so fast, and building up constraints is so simple, that you might find yourself wanting to make your validation more brutal, just because you can! Let's make sure that all the values in the hashref are really numbers; and that all the elements of the arrayref are strings:

        sub hash_add {
                state $check = compile(Num, HashRef[Num], ArrayRef[Str]);
                my ($number, $hash, $keys) = $check->(@_);
                ...;
        }

OK, so this is slower than our earlier parameter check, but not unacceptably slow; and still faster than the less strict Params::Validate check.

How??

So, how does Type::Params achieve its speed? Super optimized assembly language programming linked to via XS? Nothing of the sort; it's actually pure Perl.

It's fast because the first time you call hash_add, it generates a long string of Perl code that will be used to validate your parameters, then passes that through eval to create a custom validation coderef for your sub. (Just a glimpse of the mess of source code within that coderef is enough to give many people nightmares!) This first call is actually far slower than Params::Validate - about 10 times slower than the PP backend, but that's still under a millisecond on most modern computers.

Subsequent calls to the same function reuse that coderef, so go much faster.

The break-even point for using this trick seems to be around 20 sub calls. If your sub is going to be called more than 20 times, compiling that coderef is a sound investment. (If your sub is going to be called fewer times, then you probably don't need to worry too much about micro-optimizing parameter validation anyway.)

This is similar to what Moose does when you run:

        __PACKAGE__->meta->make_immutable;

... and it's used all over the place within the Type-Tiny distribution.

What else should I know?

Type::Params is not a drop-in replacement for Params::Validate. Their features overlap, but are not identical.

Params::Validate allows you to supply defaults for missing parameters; Type::Params does not. Params::Validate has a more natural interface for validating named parameters than Type::Params (though Type::Params can still do this). Each of them currently require Perl 5.8.1 or above, but CPAN still has old versions of Params::Validate available for Perl 5.5.

Type::Params automatically does coercion (including "deep coercions") if your type constraint has coercions defined:

        use Type::Params qw(compile);
        use Type::Utils qw(declare as coerce from via);
        use Types::Standard qw(:types slurpy);
        
        my $Rounded = declare as Int;
        coerce $Rounded, from Num, via { int($_) };
        
        sub numbers {
                state $check = compile($Rounded, slurpy ArrayRef[$Rounded]);
                my ($first, $rest) = $check->(@_);
                
                # $first is 1
                # $rest is [2, 3]
        }
        
        numbers(1.1, 2.2, 3.3);

But for me, ultimately the most compelling reason to use Type::Params is that it allows you to use the same library of type constraints for sub parameter validation that you already use for attributes in Moose/Moo/Mouse OO code.

But English is the language of Shakespeare, of Milton, of Byron, of Dylan Thomas; the language of Arthur Conan-Doyle and Agatha Christie; the language of Tolkien and C S Lewis; of Lewis Carroll and Beatrix Potter. It's the language of Stoker and Shelley.

Wikipedia notes that over 100 original novels have been published in Esperanto. Big woop-dee-doo(!)

I want to be able to use Perl 6 day to day, but not if that involves missing out on Perl 5's literature (i.e. CPAN).

Perl projects have all manner of ways of declaring their dependencies. CPAN releases usually include a file called META.yml or META.json listing their dependencies (though Makefile.PL or Build.PL is also supposed to generate a list of dependencies when it runs; this allows the release to dynamically decide on different dependencies based on the machine it's running on). Non-CPAN projects can declare their CPAN dependencies using cpanfile too.

Once the dependencies are declared, this information is used by CPAN clients, by metacpan.org (to show the list of a release's dependencies), by http://deps.cpantesters.org/ and so on.

However, this only works where you want to declare dependencies on CPAN modules, or on a minimum version of Perl itself.

For external libraries, there is good work going on in the Alien namespace on CPAN. And it seems reasonable to extend this approach to binaries.

For platforms, the solution to this has often been to include code in Makefile.PL to check $^O looks OK and die otherwise:

        die "Windows only!" unless $^O eq "MSWin32";

However, this approach doesn't leave any indication of the required platform in META.yml; it's invisible to services performing automated analysis of CPAN; metacpan.org's dependency listings won't show it.

The Platform namespace is designed as a solution to these issues.

What is in the Platform namespace?

Initially three releases. The first is Platform itself - a documentation-only release explaining the concept.

The next is Platform::Unix. This is a module that doesn't "do" anything, but will only install and only run on Unix-like platforms. So if your Perl project requires a Unix-like OS, just add a dependency on Platform::Unix, and Bob's your uncle. Having Platform::Unix listed in your META.yml and on your metacpan.org page makes it really explicit to your users that your release requires a Unix-like operating system.

The third release is Platform::Windows which is much the same thing for Windows.

Any more planned?

No, but if you have any requests, let me know. I've got a template for building new Platform releases in the Platform repository.

The traditional approach to this sort of question is to print your question to STDOUT, read a line from STDIN, and apply some sort of parsing to the answer...

   use 5.010;
   use strict;
   use warnings;
   
   my $answer;
   until (defined $answer) {
      print "Would you like fries with that?\n";
      $_ = <>;
      $answer = 1 if /^Y/i;
      $answer = 0 if /^N/i;
   }
   
   say "Adding fries!" if $answer;

One issue with this approach is: what happens when your script is not running in a terminal?

   use 5.010;
   use strict;
   use warnings;
   use IO::Prompt::Tiny qw(prompt);
   
   my $answer;
   until (defined $answer) {
      # In non-interactive mode, assume they want no fries...
      $_ = prompt("Would you like fries with that?", "No");
      $answer = 1 if /^Y/i;
      $answer = 0 if /^N/i;
   }
   
   say "Adding fries!" if $answer;

The problem with this is that it makes the assumption that when the terminal is non-interactive, there is absolutely no other way to prompt the user, and you should be happy with the default answer. This is not always a good assumption.

Opening up a dialogue

On some operating systems, double-clicking a Perl file will launch it without a terminal. In these cases, you can probably interact with the user by launching a dialog box. But how to do that? Doesn't that require complex programming in Tk or Wx (modules which are not in core, and not always straightforward to build)?

Enter Ask. Ask abstracts away the details of interacting with your user. It will do the terminal interaction test; it will check PERL_MM_USE_DEFAULT; it will see if the Wx, Gtk2 or Tk modules are installed and usable; it will even use /usr/bin/zenity (a GNOME component for adding GUI dialog boxes to shell scripts) if it has to.

It will only resort to using the default answer if there's no other possibility of interacting with the user. Here's our fast food worker using Ask:

   use 5.010;
   use strict;
   use warnings;
   use Ask qw(question);
   
   my $answer = question("Would you like fries with that?", default => 0);
   say "Adding fries!" if $answer;

That is the question

In the previous example, we saw a yes-no question. How about something a bit harder?

   use Ask qw( multiple_choice );
   
   my @answers = multiple_choice(
      "Please choose some pizza toppings...",
      choices => [
         [ sauce        => 'Our famous pizza sauce' ],
         [ cheese       => 'Oozing Mozzarella cheese' ],
         [ ham          => 'Finest Bavarian ham' ],
         [ pepperoni    => 'Spicy pepperoni' ],
         [ onion        => 'Onion slices' ],
         [ tinned_fruit => 'Chunky cuts of fresh pineapple' ],
      ],
   );
   say "Adding $_" for @answers;

Or if you just wish them to choose a single option from a list:

   use Ask qw( single_choice );
   
   my $existance = single_choice(
      "To be, or not to be; that is the question.",
      choices => [
         [ be     => "Be" ],
         [ not_be => "Don't be" ],
      ],
   );

Ask also has functions for file selection, text entry (including hidden text - passwords) and displaying information, warnings and errors.

I object!

If you object to using the functional interface, you can get an object using the Ask->detect method and call question, single_choice and friends as object methods.

   use 5.010;
   use strict;
   use warnings;
   use Ask;
   
   my $interface = Ask->detect;
   
   my $answer = $interface->question(
      text      => "Would you like fries with that?",
      default   => 0,
   );
   say "Adding fries!" if $answer;

The functional interface is just a friendly wrapper around Ask's object-oriented core.

Boldly go

Let's say that you want to hook up your script to your drive-through restaurant's voice recognition system. Ask's backends are all Moo classes performing the Ask::API role. It's really easy to write your own:

   package Ask::VoiceRecognition {
      
      use MyApp::Voice::Generator ();
      use MyApp::Voice::Recognition ();
      
      use Moo;
      with 'Ask::API';
      
      has generator => (
         is      => 'lazy',
         default => sub { MyApp::Voice::Generator->new },
      );
      
      has recognition => (
         is      => 'lazy',
         default => sub { MyApp::Voice::Recognition->new },
      );
      
      sub info {
         my $self = shift;
         my %args = @_;
         $self->generator->say($args{text});
      }
      
      sub entry {
         my $self = shift;
         my %args = @_;
         $self->info($args{text}) if exists $args{text};
         return $self->recognition->listen(seconds => 30);
      }
   }

That's all there is to it!

The Ask::API provides default implementations of question, file_selection, multiple_choice, etc, which you can override if you choose to, but that is optional.

To force Ask to use your backend rather than the built-in ones, just set the PERL_ASK_BACKEND environment variable to the name of your module.

Ask the future

Ask is a young module and still needs some work. In particular:

• Detection of the best module for interacting with the user is naive. It can end up selecting, say, Gtk2 on a headless Linux box.
• A native Windows GUI backend is planned. The Gtk2, Wx and Tk backends should all theoretically work on Windows, but rely on various library files being present.

Ask is on GitHub and on Bitbucket so feel free to contribute improvements!

Meh... so now I notice I forgot to list the pre-requisites...

When Moo detects Moose has been loaded, it "inflates" all Moo classes and roles into Moose classes and roles, so Moo code integrates with Moose code perfectly. Because of this, and Moo's very light memory and CPU footprint, many Moose-based projects are migrating to Moo. High profile migrations include Throwable, Message-Passing and MooseX-Role-Loggable.

Not all Moose-based projects are easy to port to Moo. Some require a high level of introspection and meta-hackery that only Moose can provide. But if Moo does seem to be a good fit for your project, switching to Moo is not as simple as dropping the "se" from your "use Moose" lines. There are a number of incompatibilities between the declarative syntaxes of Moo and Moose.

I've recently released MooX-late to help smooth over the differences and translate Moose code to Moo. Currently it handles:

• stringy type constraints, like isa => "Str"
• non-reference defaults, like default => 1
• Moose's lazy_build shortcut
• Exporting the blessed and confess functions like Moose does

But I'd love to hear what other people think are the Moo annoyances. What is preventing you from porting simple classes and roles to Moo? What does Moose do for you that Moo does not? What features should I add to MooX-late?