Thoughts on Predicates and/or Matchers

Rob is working on making filter development easier. Currently whenever a user wants to do some custom filtering, they need to extend our AbstractFilterList and implement its filterMatches(Object) method. This gets the job done but there's some problems:

Discourages code reuse from the filterMatches() method

Reinventing the wheel: many users will end up implementing common requirements like a filterMatches() that tests if an element is in some other list.

Slow: implicitly pairs one AbstractFilterList (and associated costs) for every matching strategy

Not dynamic: filterMatches() method does not lend itself to different behaviour over time

Therefore we're building something smarter using predicates, or as we like to call them, Matchers. Since Matchers aren't exactly predicates, the name-change makes sense. For example, rarely do predicates fire events when their match logic is modified!

Matchers are great. We can build in a library of ready-to-use matchers for common tasks such as:

Testing for equality with any object, null or otherwise. Via '==' or even '.equals()'

Testing for containment in some other set

Comparison to a constant.

Thresholds

instanceof, .getClass()

Composition of multiple matchers with AND, OR, NOT, XOR etc.

Delegate matchers. I can delegate to another matcher using an extracted bean property of the tested object.

Of course the above Matchers stuff will require a lot of code! Rob's written a lot of it already, but I have this (irrational?) fear that we're getting away from our 'core competency'. Why is this a problem?

That code is going to want to be maintaned! It will require at least one huge effort when we migrate to Java 5.

We're all-of-the-sudden becoming a toolkit for more than list transformations. From here it would seem natural to add Closures as well, since they are necessary for building delegation-capable predicates.

There's already at least three open source predicate toolkits. They're all incompatible with different merits and design goals. We will simply be yet another incompatible implementation to add to the mix. Adapters simplify this problem, but there are limitations! For example, no other predicates toolkit that I found used events to send notification of a mutation. And this feature is a must for our implementation!

So what is the solution? Obviously matchers are a good thing and we want them in our code. Rob is a hell of a coder and he's dedicated to matchers, so most of my complaints about the required effort are muted. But I still think we're getting away from our core-competency! Yuck.

# posted by Jesse Wilson on Saturday, February 26, 2005