| Subject: | Type::Tiny and when() |
Considering the somewhat murky future of when() I don't know if this is even reasonable to suggest, but a particular use-case for me with Type::Tiny types is to create a type library related to Exception objects for use in a Try::Tiny catch block along with when().
For example, consider that I have an exception class named Exception::FileOpen and a Type::Tiny class_type restraint pointing to it named FileOpenError. I want to be able to do this:
try {
...
}
catch {
when(FileOpenError) {
...handle file open exception...
}
default {
...all other exceptions...
}
};
This seems like, to me, a particularly elegant way to handle this sort of exception catching. The problem is, given the way that when() works (as of 5.18.2), since FileOpenError is a subroutine, when() evaluates the return value in boolean context (which Type::Tiny overloads to always be true), when what I want is for it to apply a smartmatch and thus perform a ->check() operation against $_.
The last time I heard, I believe the standing proposal by rjbs was to make when() always perform a smartmatch, which would solve this issue, but I don't really know the status of those changes. In the meantime the easiest way to achieve this behavior would be to have boolean context overload to calling a check on $_ but I don't know how desirable that is. Either way, I figured it wouldn't hurt to explain my use case.
A non-ideal workaround would simply to do something like this:
when (my $e = FileOpenError) {
}
So that when() operates on a scalar and thus uses smartmatch, but I'm somewhat concerned about false positives when (not if) people on my team forget to do this.