Front page | perl.moose |
Postings from July 2008
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 <stevan.little@iinteractive.com>
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
>>> <stevan.little@iinteractive.com> 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
Thread Previous
|
Thread Next