Predicate vs. Matcher

[Cantor, Scott]

I found a much more concise example of the point I was belaboring:

net.shibboleth.idp.attribute.filter.impl.filtercontext
AttributeRequesterMatcher



Pretty much the standard policy requirement rule matcher we all use.

We're shoehorning in the Predicate interface, but all the logic that
implements the predicate is in the doCompare method. The Predicate gets
created as an anonymous class that calls that method on the Matcher object.

I'm trying to say I would either make AttributeRequesterMatcher a
Predicate directly, or dump the Predicate bit and just let
AttributeRequesterMatcher be the Matcher it already is and override
whatever method is appropriate (possibly the one it's already overriding,
so the work is minimal).

I don't think the Predicate thing is accomplishing anything because it's
tightly bound to the Matcher classes. The original idea I think was that
the Predicates would be generic and shared across subsystems and not
specific to the filtering engine.

I don't know if that's feasible, but this isn't giving us that reuse right
now.

-- Scott