Evaluable criteria

[Cantor, Scott]

On 6/2/15, 9:15 AM, "dev on behalf of Marvin Addison" <dev-bounces at shibboleth.net on behalf of marvin.addison at gmail.com> wrote:

>
>Offhand, it seems there's an easy solution: make three different Criterion classes, one for each type, then give CriteriaSet intelligence to do any/all/other combinations for multiple matches. I guess I'm making an academic argument at this point since I clearly haven't spent as much time as you have, so I'll just trust that the current design is best for the given cases.

You can have three different classes, but they can't implement a common generic interface. You end up where we are, supporting explicit Criterion classes, so it's not really much of a change.

>That seems odd to me. What's the point of caller having control over criteria if he/she doesn't know what types are in play for criteria evaluation?

Because the types in play are the business of the resolver. You might know some or all of the public types involved, but the internal implementation may be entirely different. If you stored metadata in a database, you would never want to evaluate an entityID criterion by running a Predicate over EntityDescriptor, you'd issue a select. You need an actual EntityIDCriterion to give you the where clause.

-- Scott