(Solved?) Moose type-constraint is unhappy with defaults ... why?

sundialsvc4 has asked for the wisdom of the Perl Monks concerning the following question:

I have this ...

package myTypes;
use MooseX::Types -declare => [
    qw( myOffset ) ];
...
subtype myOffset,
    as Int,
    where { ($_ >= 0) && ($_ <= 99) },
    message { "offset '$_' is invalid (out of range)."}
    ;
[download]

and in the object ...

use myTypes qw( myOffset );
...
has 'my_offset' => (
    is       => 'rw',
    isa      => 'MyOffset',
    default  => 0,
);
[download]

And when I instantiate the object:

Attribute (my_offset) does not pass the type constraint because: Valid
+ation failed for 'MyOffset' with value 0 at constructor ...
[download]

Changing it to isa => 'Int', for example, allows the constructor to continue. I have confirmed that is_MyOffset(0) is true. All of the edge-cases work.

On closer look, it appears that any use of a isa=>'some_subtype' is refusing to accept the default value even when the where clause for some_subtype says that it should. (For example, taking a definition PositiveInt straight out of the Synopsis of MooseX::Types, the message will appear if the default is 1.

Fudging the isa string to produce a bogus type-name fails immediately (as is correct), and removing the where clause from the existing subtype removes the problem. So it certainly would appear that the subtype, and its associated where clause, is being found and executed.

Edit: On closer inspection of the documentation (what? what%squo;s that?) for MooseX::Types, I see that they recommend using barewords for the types, noting also that this will cause compile-time error goodness. (MooseX::Types::Moose provides the standard Moose types.) Making this change resolved the problem, although I remain somewhat fuzzled as to why it occurred.)

Comment on (Solved?) Moose type-constraint is unhappy with defaults ... why? Select or Download Code

Replies are listed 'Best First'.
Re: (Solved?) Moose type-constraint is unhappy with defaults ... why? by zwon (Abbot) on Nov 24, 2011 at 16:06 UTC
First of all you're declaring type `myOffset` and then using `MyOffset`, note that case is different. Anyway, let's assume that's typo and you're using `MyOffset` everywhere. If you're declaring your attribute as `has my_offset => (is =>'rw', isa => 'MyOffset');` [download] Moose will expect `my_offset` to be reference to 'MyOffset'. And it has no idea how to coerce this from integer. Now, if you're declaring your attribute as `has my_offset => (is =>'rw', isa => MyOffset);` [download] it will call function `MyOffset()`, which returns "myTypes::MyOffset", so it is the same as if you'd write it as: `has my_offset => (is => 'rw', isa => "myTypes::MyOffset");` [download] and `myTypes::MyOffset` may be coerced from integer.	[reply] [d/l] [select]
Re: (Solved?) Moose type-constraint is unhappy with defaults ... why? by phaylon (Curate) on Nov 24, 2011 at 17:34 UTC
The main reason for MooseX-Types at the time was that since Moose types are global, you have to be careful about conflicts. Your "MyOffset" type for example is not very distinct. Another module could easily have that type itself. So it became best practice to name them "MyProject::MyType" with a project prefix. So MooseX-Types is there to do the following for you: Encapsulate your types into a reusable library from which you can import the types into your current package. Provide the types as exported functions so typos can be caught. Handle namespacing of the types so they don't conflict. The last part is crucial here. Since the declared types are namespaced, your type is actually named "myTypes::myOffset". If you use the bareword you don't have to type out the namespace, among other things. So basically what zwon++ said is right, just wanted to give some context as to the reasons of why it is this way. Ordinary morality is for ordinary people. -- Aleister Crowley	[reply]


Your skill will accomplish what the force of many cannot
	PerlMonks