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.

Reply via email to