You also have all the options passed in creation. As long as you are not
using attribute override (has +), you have what you need, I think?
Something like this:
before _process_options => sub {
my ($class, $name,$options) = @_;
$options->{default} = sub {
my $resp;
my $type;
if ($options->{isa}) {
$type =
Moose::Util::TypeConstraint::find_or_parse_type_constraint($options->{isa});
}
while (! defined $resp) {
$resp = get_input_from_lazy_user($name);
if ($type) {
if ($type->has_coercion) {
$resp = $type->coerce($resp);
}
if (! $type->check($resp) {
$resp = undef;
}
}
return $resp;
};
}
If you are using attribute overrides, etc, then look at the code I
submitted originally.
On Thu, Dec 22, 2011 at 6:21 PM, Buddy Burden <barefootco...@gmail.com>wrote:
> On Thu, Dec 22, 2011 at 3:51 PM, Edward Allen <edw...@allenthree.com>
> wrote:
> > As long as you document what you are doing so that the poor sap who has
> to
> > maintain your code after you win the lottery can figure it out, I say go
> for
> > it! Wrapping _process_options is time honored, convenient, and an
> absolute
> > must technique for any mooser, imho.
>
> Thanks for the encouragement guys! Okay, one more question ...
>
> Since I'm wrapping _process_options, I'm being called from new() ...
> that is, the new() for the attribute itself. I.e. the attribute
> doesn't really exist yet, as it's in the process of being created.
> Which I normally wouldn't care about, but I got to the point where I
> want my prompting routine to verify that the user-supplied value will
> pass the type constraint when assigned to the instance's attribute
> slot. If I _don't_ do this, the program will just blow up. What I'd
> rather it do is validate the value using the attribute's type
> constraint, then just reprompt upon failure. But the attribute
> doesn't exist at the time I create the prompting routine, so I _have_
> no type constraint to use for checking. All I have is the name of the
> attribute,(*) which I keep thinking I should be able to leverage
> somehow, but I have neither the classname the attribute belongs
> to--which probably wouldn't be sufficient anyway--nor an instance
> pointer, which of course doesn't even exist at the time I'm executing.
> (Man, this keeping straight all the various levels and times things
> are running at is the hardest part of this Moose stuff ...) And,
> since I'm creating a default sub, the actual assignment is happening
> elsewhere too, so I can't even wrap that in a try block to catch the
> type constraint error.
>
> So, anyway: ideas? I'm going to keep plugging away, but I thought I'd
> ask here as well.
>
>
> -- Buddy
>
>
> (*) Technically, this is not true. Technically, I have access to the
> raw 'isa' of the attribute as well. But trying to turn that into a
> type constraint seems ... hacky. And error-prone. And inefficient,
> since the Moose code is just going to do it again anyway.
>
