On Monday, April 29, 2013, Bill Moseley wrote:
> On Mon, Apr 29, 2013 at 11:18 AM, Chris Prather
> <ch...@prather.org<javascript:;>>
> wrote:
>
> > On Mon, Apr 29, 2013 at 2:03 PM, Karen Etheridge
> > <p...@froods.org<javascript:;>>
> wrote:
> >
> > > Altneratively, you might find the augment/inner method modification
> > pattern
> > > to be of use -- a method can always opt to not call inner() if it has
> had
> > > its preconditions satisfied already. (Actually, this is probably
> better
> > > than my first suggestion.)
> > >
> > >
> > I'm not sure augment/inner is ever the right answer, but it's certainly
> > better than relying upon Role application order.
> >
>
> In my case the order is not really important -- just need to find the first
> one that succeeds. Although, in general I could see situation where the
> order would be important.
>
> I'm not following the code below. Do you have an array or roles brought in
> using "with"? Or instances of classes that all have an authenticate()
> method? What I'm not understanding is how you are calling the
> authenticate method in each role.
>
>
The roles have been translated to objects that each implement only the
authentication logic that you currently have in Roles. Perhaps the type
constraint is confusing things:
subtype AuthPlugin => as Object => where { $_->does('MyApp::AuthPlugin') };
# an equivalent Type Constraint
which effectively is:
subtype AuthPlugin => as Object => where { $_->can('authenticate') }; #
equivalent to a duck_type than role_type.
You then iterate over this list of objects, having each one try
to authenticate accordingly.
My other thought was a parameterized role where I pass in a list of
> authentication classes where each has an authenticate method and then call
> them in a loop as you have below.
>
>
You could that that yes, but in my opinion it would be serious overkill.
You seem to be hung up on "a solution involving Roles" when really "a
solution involving delegates" would work just as well.
>
>
-Chris
