develooper Front page | perl.moose | Postings from June 2011

Re: Moose Type Constraints violations to warnings?

Thread Previous | Thread Next
June 13, 2011 06:24
Re: Moose Type Constraints violations to warnings?
Message ID:
----- Original Message -----

> From: Stevan Little <>
> Yes, Chris is correct, I (and most of the rest of the Moose dev group) think 
> that turning off type-checks is a bad idea. I cannot speak for Mouse though.

I don't want to turn off the type checks. I would just like some of them to be warnings if we're in production.

I agree completely with the *concept* of the strict type constraints, but 

  "In theory, theory and practice are the same.
  In practice, we're trying to comb spaghetti."
  Abraham Lincoln, 1912 speech to the Republican Women's De-emancipation Convention

If a hotel's "short description" must be no longer than 200 characters, they would much prefer to have the first 200 characters of their hotel's 250-character description displayed rather than nothing.

We have a large, complicated system and there are many, many attributes whose values can be set in annoying mysterious ways and from data sources not always under our control. A few attributes must *never* be incorrect (or if incorrect, must fall within certain tolerances, such as not having a negative hotel room price). However, we'd rather show our customers the wrong size thumbnail and get a warning in our error log than a nifty 500 page.
By allowing us to optionally convert some fatal warnings to "advisory" constraints (no, I have no idea how to generalize this), we can gradually understand the source of our errors (and perhaps better understand if the fault lies with the data consumer rather than the data producer) and gradually work on them. Just immediately switching from:

    sub short_description {
        my $self = shift;
        return @_ ? $self->{description} = shift : $self->{description};


    has short_description => (
        is  => 'rw',
        isa => 'ShortDescription', # with a length constraint

Has led to all sorts of grief and this is part of the reason why we've had a lot of pushback on Moose/Mouse.

Even those who object to Moose/Mouse agree that we're happy to keep it if we can clearly show an improved development speed with little loss of performance, but having to set up a bunch of TypeConstraints which convert to warnings under production can take time, but just switching to "isa => 'Str'" won't allow us to see where the errors are and gives us little perceived advantage over Class::MethodMaker and similar options.

So yes, I agree that we *should* have strict type constraints, but our problem at work is more than just theoretical. Just one type constraint causing 500 errors instead of warnings can literally cost us many thousands of euros.

That being said, considering all of the excellent feedback in this thread, I expect we'll pursue an option like this:

    package Bookings::TypeConstraints;                                                                                  

    use Any::Moose;
    use Any::Moose '::Util::TypeConstraints';

    BEGIN {

        # set up "must never fail" types here

            # advisory constraints with fatal violations
        else {
            # advisory constraints with warning violations

Can anyone suggest an improvement?


Live and work overseas -
Buy the book -
Tech blog -
Twitter -

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About