Re: checking consistency between attributes

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
>
>
>