Re: checking consistency between attributes

I'm very anxious to see what come of this as I agree that this would
be very cool but I fail to see how it would help with the initial
question as triggers to not get fired until after construction?






On 7/16/08, Stevan Little <[email protected]> wrote:
>
>  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
> > > >
> > >
> >
> >
> >
> >
>
>


-- 
benh~