I'm also referring to the behavior of Type::Params which would not be
affected by Moose/Moo/etc
Although all kinds of conveniences are needed, the biggest probably
has been figuring out which attribute/what type got thrown (names, not
necessarily the validation code itself as I'm unlikely to return
class/regex to a UI).
Parsing strings is problematic at best. Even if Moo/Moose were still
failing it might be a step towards making them better (they need a new
type system IMO)
you wouldn't necessarily have to add a dependency, rather support an
interface. Dependency Inversion Principle.
Internally it might look something like this
my $obj = $class->new( message => ..., ... )
$obj->throw()
How you might let it be used (note: I don't really like doing this in
an import statement, it makes it hard to inject the type validator)
use Type::Params
compile => { class => 'Throwable::Error' },
validate => { class => 'Exception::Base' },
;
even better might be something like this, which would be really easy
to inject into my objects at runtime
state $check = Type::Params->new(
compile => { class => 'Throwable::Error' },
validate => { class => 'Exception::Base' },
)->compile( ... );
ultimately it would allow me to write stuff like
package Test {
use Moose;
has _validator => (
...
);
}
Test->new( _validator => Type::Params->new( ... ) )
which could be done by something like Bread::Board, and now I too am
simply coding to an interface.
On Thu, May 9, 2013 at 8:38 AM, Toby Inkster via RT
<bug-Type-Tiny@rt.cpan.org> wrote:
Show quoted text> <URL:
https://rt.cpan.org/Ticket/Display.html?id=85149 >
>
> It's also worth noting that even if Type::Tiny emits exceptions for "assert_valid" and so on, this wouldn't necessarily change the behaviour you see when the type constraint is used for a Moose/Moo attribute.
>
> Moose throws its error by calling the type's "get_message" method, interpolating that into a string, and then confessing that string.
>
> Moo catches whatever error message the type constraint tries to throw (using $SIG{__DIE__}, not eval), and concatenates that with another string, then dies with that string.
>
> In both cases, an exception object wouldn't survive the OO framework's post-processing.
--
Caleb Cushing
http://xenoterracide.com