Here's a good practice: Leave the attribute constraint strict all the time, and provide a coersion functionality to examine the raw input and reformat it from the variety of formats there might be so that it either matches the strict definition or fails because it can't be converted. -- Darren Duncan

Heiko Jansen wrote:
Guys,

I´m trying to implement a Moose-based module for objects according to
some standard.

The standard tells us, that the objects may have a fixed set of
attributes with a defined structure.

There is, for example, a "date" attribute which should conform to "YYYY-MM-DD".
So as a simple first approach I defined an attribute "date" having as
type a subtype of Str which conforms to the regex
/\A(1[4-9]|20)\d\d-\d\d-\d\d\Z/. (Not very sophisticated, but probably
enough for this mail).

Now on one hand I want to make sure that the objects we create in our
software are valid.

On the other hand we see non-standard-compliant attribute values (e.g.
"12/01/1980" for "date") in incoming requests so that type checking
fails when parsing these requests.

However, I don´t want the parsing to fail in most cases, because the
quality of results computed over the inaccurate data will likely
degrade but not be completely useless.

So I´m looking for a way to switch on either strict or relaxed type
checking but I don´t know how.

The only solution I could think of was looking at a package-global
variable within the type checking code:

... where { if ($PKG::STRICTMODE) { $_ =~
/\A(1[4-9]|20)\d\d-\d\d-\d\d\Z/ } else {1} };

But I´d rather like to make the decision within an object scope like so:

Pack::MyClass->new( strict => 0 )->parse( $uri );

I haven´t got much experience using Moose and am hoping for someone to
share her/his experience on solutions considered good practice.

Thx.!
Heiko


Reply via email to