Ohh, I like this, very clean and re-using existing documentation :P
It keeps it away from the type system too, which while it feels kinda
sexy to integrate it with, it also feels wrong (not the good wrong,
but the bad wrong).
Sartak++ very very *very* well volunteered :)
- Stevan
On Jul 15, 2008, at 9:05 PM, Chris Prather wrote:
On Tue, 15 Jul 2008 20:55:44 -0400, Sartak wrote:
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?
I second continuing the method modifier theme into triggers here.
Sartak hits the nail on the head, before/after/around are nicely
extended into this realm too. Keeping the theme means less confusion
when it comes time to document/explain this to people who are ...
shall
we be kind and say intermediate moose users ... cause this is getting
well into the advanced realm.
Well volunteered Sartak!
-Chris
