2010/1/19 Hans Dieter Pearcey <h...@pobox.com>:
> 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 $_.
>>
>> 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.
That's clarified things a great deal. Thank you for taking the time to
help me though this.
Dp.
