----- Original Message -----
> From: Stevan Little <[email protected]>
>
> 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};
}
To:
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
if ( $ENV{HARNESS_ACTIVE} || $ENV{USE_STRICT_TYPE_CONSTRAINTS} ) {
# advisory constraints with fatal violations
}
else {
# advisory constraints with warning violations
}
}
Can anyone suggest an improvement?
Cheers,
Ovid
--
Live and work overseas - http://overseas-exile.blogspot.com/
Buy the book - http://www.oreilly.com/catalog/perlhks/
Tech blog - http://blogs.perl.org/users/ovid/
Twitter - http://twitter.com/OvidPerl/
