Re: checking consistency between attributes

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