Excerpts from Dermot's message of Tue Jan 19 11:00:41 -0500 2010:
> my $indexer = MyApp::Local::Indexer->new(index_type=>'foobarquin);
> I thought $_ was the value passed by the constructor arguments. In
> this case, $_ ='foobarquin' and it would been used to cmp against the
> strings in the array.
No, that's not how Perl works. There's nothing magical that defers $_'s
evaluation until later. It's just a global variable. In the context of type
constraints, it's only useful in blocks (where, via, message), which *are*
evaluated later -- but again that has nothing inherently to do with $_.
> subtype 'IndexType',
> => as enum( [qw(foo bar baz)] ),
> => message {'Wrong type'};
> has 'index_type' => (isa => 'IndexType');
>
> now the above works. Is this a correct implementation? Could this have
> been done with a named enum? Would it make sense to create a named
> enum type inside a subtype?
Yes, yes, and probably not -- declaring a named type offhandedly inside the
subtype declaration seems like a good way to confuse yourself. And again,
enum($name, \...@values) is not documented to return the new enum type
constraint.
> The docs say that you can construct constraints with
> subtype 'Name' => as 'Parent' => ....
>
> Are these 'Parents' objects the class_type, duck_type and enum as well
> as other Classes you might want to harness?
Yes and no. Yes, it is class_types, duck_types, enums, 'Str', 'Int', etc.; and
no, it is not "as well as other classes", it's *only* type constraints -- when
you give a class name, Moose sees that it doesn't have a type constraint named
Foo, so it assumes that you meant class_type("Foo") instead. Because this is a
guess, Moose can theoretically get it wrong, so you may want to explicitly use
class_type instead.
hdp.
