On Jul 16, 2008, at 4:39 PM, Charles Alderman wrote:
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?)
No, that is all that needs to be done. The initial reasoning for
those restrictions was to try and enforce some sanity into things
rather then let them be changed randomly, blah blah, something about
Liskov, etc. I mean there is something to be said for protecting
users against their own stupidity here.
But as time goes by there seems like the only sane restriction is
really the "isa/does must be a subtype" thing, and probably weak_ref
and auto_deref since they can break things in subtle ways if not used
properly by the super class you are overriding from.
So I guess I am saying yes, we can add trigger to the list of legal
options.
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?
No, the override is not cumulative, it simply overrides it
completely, so the foo trigger would only have an "after" for it.
This is maybe the only place where this would be bad, so perhaps we
should wait till Sartak finishes and see what we get before we add it
to the legal options.
- Stevan
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
