Domain-specific Matchers factory classes

[npryce]

CoreMatchers and Matchers are now in the source and both compiled into the same JAR. CoreMatchers is therefore redundant. Matchers is growing larger and larger, to the point that autocomplete in the IDE is awkward.

Therefore,

• Split CoreMatchers and Matchers into domain-specific classes. E.g. ListMatchers, MapMatchers, StringMatchers, NumberMatchers, etc.
• At a later date, we will deprecate Matchers and CoreMatchers and eventually delete them.

[sf105]

Should we use naming scheme ListMatchers, CoreMatchers, ObjectMatchers, etc? Reads better to me and avoids having to rename some existing factories (e.g. FileMatchers).

[npryce]

See the discussion with Colin Vipurs on the Hamcrest Java mailing list about how to better aid IDE autocomplete: https://groups.google.com/d/msg/hamcrest-java/0x6brgczThc/lF8LDTaneBoJ

[sf105]

OK. How about MatchingX? Less like to include unrelated MatchX types?

[npryce]

Yes. After using the MatchXxx convention a bit I do find that autocomplete brings in too many unrelated suggestions. MatchingXxx would filter them out.

[npryce]

I'm not sure where to put the logical composition operators, such as allOf, anyOf, not, anything().

Maybe we should keep the Matchers class around for those. But "Matchers" doesn't fit the MatchingXxx naming convention. Is that a problem? Or should we introduce a new Matching class just for those, and eventually deprecate and remove Matchers?

In Java 8 they could be static methods of the Matcher interface but in Java 7 we still need a class for them.

[sf105]

I haven't pushed, but I've been moving the match classes into the relevant library subdirectories. Then referencing the most common matches in CoreMatchers. At some point I'll merge the core and library trees.

core now contains combiners and IsEquals which I figure is pretty fundamental.

I suggest we leave Matchers, which is deprecated anyway. Maybe CoreMatchers could become MatchingCore. Not sure.

In Java 8 I think we get method references, so it all becomes easier.

I've also introduced a FunctionalMatcher that uses a function for feature extraction, in prep for Java 8.

S

On 27 Dec 2014, at 21:37, Nat Pryce notifications@github.com wrote:

I'm not sure where to put the logical composition operators, such as allOf, anyOf, not, anything().

Maybe we should keep the Matchers class around for those. But "Matchers" doesn't fit the MatchingXxx naming convention. Is that a problem? Or should we introduce a new Matching class just for those, and eventually deprecate and remove Matchers?

In Java 8 they could be static methods of the Matcher interface but in Java 7 we still need a class for them.

—
Reply to this email directly or view it on GitHub.

[npryce]

Have you pulled? Because I already did that on the v7.0 / v2.x branch some time ago.

[sf105]

OK. What do you want to do?

I've unpublished my v7.0

We should rename v2.x to v2.0

I'd better stop work for now because I'm getting confused.

S

On 28 Dec 2014, at 19:40, Nat Pryce notifications@github.com wrote:

Have you pulled? Because I already did that on the v7.0 / v2.x branch some time ago.

—
Reply to this email directly or view it on GitHub.

[npryce]

Don't rename the branches. At least not yet. The branch name is not that important. We can tag and rename it when we do the release.