On Tue, Jul 15, 2008 at 8:29 PM, Stevan Little
<[EMAIL PROTECTED]> wrote:
> trigger => {
> before => sub { ... },
> after => sub { ... },
> }
+1 awesome
> The idea would be that the "after" would do the same as the normal trigger,
> and the "before" would get the same arguments as the normal trigger except
> the assignment would not have happened yet. The tricky bits are:
We already have something vaguely like this: method modifiers!
Modeling multi-phase triggers after method modifiers would decrease
cognitive load.
> - do we make the "before" trigger return a value for us to assign?
No. The return value is discarded.
> - do we make the "before" trigger actually do the assignment?
No. The before trigger is only there to perform additional validation
or to call extra methods.
We could have an "around" trigger which *does* wrap the assignment.
> - what happens if an exception is thrown inside the "before", do we catch
> it?
No. Exceptions are generally outside of the scope of Moose. We only
throw them. :)
Besides, before could be used mostly for exceptions, to do multi-value
validation.
> - how would you/should you be able to -- indicate failure or some kind in
> before?
Throw an error. This is what we do and expect practically everywhere
else, right?
Shawn
