Speaking of triggers, why can't the trigger of an attribute be changed
in an extended attribute? Like so:
has '+foo' => ( trigger => sub {} );
The docs only say the "feature is restricted somewhat, so as to try
and force at least some sanity into it. You are only allowed to change
the following attributes: [a list not including trigger]."
Would it be as easy as adding "trigger" to
Moose::Meta::Attribute::legal_options_for_inheritance()? (I tried
that, and it worked initially. Am I missing some un-intended
side-effects somewhere?)
I guess there would be some screwiness (undecided behavior) in
Sartak's plan for the method-modifier-like triggers? Thusly:
package Foo;
use Moose;
has 'foo' => (
is => 'rw',
trigger => { before => sub{} }
);
package Foo::Bar;
use Moose;
extends 'Foo';
+has 'foo' => ( trigger => { after => sub{} } );
Would foo trigger before AND after now?
Thanks,
Charles Alderman
----- Original Message -----
From: Stevan Little <[EMAIL PROTECTED]>
Sent: Tue, 15 Jul 2008 23:05:32 -0400
Re: Re: checking consistency between attributes
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
