Matcher.and(Matcher)

[GoogleCodeExporter]

allOf(Matcher...) is a fine api, but it's not typesafe (as javac likes to
remind me), and it doesn't read quite right.

Creating a Matcher.and(Matcher) syntax solves both of these problems.  I
guess that Matcher.or(Matcher) would then also have to be added.

Original issue reported on code.google.com by david.s...@gmail.com on 31 Jan 2007 at 7:48

[GoogleCodeExporter]

Actually, there's another way to do this that doesn't require any change to the
Matcher API:

both(matcher1).and(matcher2)
either(matcher1).or(matcher2)

Thoughts?

Original comment by david.s...@gmail.com on 9 May 2007 at 3:45

[GoogleCodeExporter]

Would that also have to include?

allOf(one).and(two).and(three)
anyOf(one).or(two).or(three)

Original comment by smgfree...@gmail.com on 9 May 2007 at 3:57

[GoogleCodeExporter]

Matcher.and and .or kind of dirties the API of Matcher a bit too much I think.

We need some sort of sugar such as both or allOf but I'm not sure how it should 
yet:

allOf(one).and(two).or(three) - Is that clear?

I guess the implementation should be a builder that also implements Matcher and
delegates as necessary?

Original comment by neild...@gmail.com on 9 May 2007 at 4:07

[GoogleCodeExporter]

Neil,

Exactly.  I imagine

BooleanBuilder<T> both(Matcher<T> matcher)

and

class BooleanBuilder<T> {
  <U extends T> BooleanBuilder<T> and(Matcher<U> matcher);
  <U extends T> BooleanBuilder<T> or(Matcher<U> matcher);
}

I like "both" better than "allOf" because "both" serves an introductory role in
English.  "both green" is clearly an incomplete thought expecting an "and", but 
"all
of green" sets up no similar expectation in my head.  Also, overloading the name
"allOf" to have both the 1.0 meaning (expecting an array of matchers), and the 
new
meaning (returning a builder that expects more boolean operators) seems 
confusing.

Original comment by david.s...@gmail.com on 14 May 2007 at 7:00

[GoogleCodeExporter]

My only issue is that 'both' and 'either' imply just 2 items. 

I also worry about the symmetry of this. I know we are trying to make this 
literal,
but it's also a computer program and the parenthesis are in the wrong place.

XX(x, y) vs XX(x).XX(y) 

Original comment by joe.wal...@gmail.com on 17 May 2007 at 10:05

[GoogleCodeExporter]

Joe,

True that both and either imply two items.  On that note, would you prefer
allOf(x).and(y), etc.?

It would be great to have and(x, y).  I agree that literate interfaces are 
secondary
to good object and functional design.  The type safety concern is the more 
important
one here.  In conclusion, allow me to paste in a comment from a mail thread that
somehow spun off of this issue without leaving an audit trail:

On 5/9/07, Nat Pryce <nat.pryce@gmail.com> wrote:
> What's wrong with allOf(one, two, three) and anyOf(one, two, three) ?

a) They require suppressions in order to compile without warnings.  If
I remove the line

@SuppressWarnings("unchecked")

from AllOfTest.java, I get 7 compile warnings, all saying "Type safety
: A generic array of Matcher<FactoryMethod> is created for a varargs
parameter"

b) This does not compile:

       allOf(notNullValue(), containsString("a"));

This can:

       both(notNullValue()).and(containsString("a"));

c) Less important, but still interesting: "both / and" is much clearer
English to me than "allOf(...)"

Original comment by david.s...@gmail.com on 18 May 2007 at 12:59

[GoogleCodeExporter]

I've just committed a change that changes the anyOf()/allOf() signatures:

Before:
  Matcher<T> anyOf(Matcher<T>... matchers)

After:
  Matcher<T> anyOf(Matcher<? extends T>... matchers)

This addresses the compile errors and removes the need to suppress warnings.

eg:
  allOf(notNullValue(), containsString("a")); // now works.

I'm marking this issue as fixed for the moment. If you're still interested in 
the
.and() thing, let's discuss on the mailing list.

cheers
-Joe

Original comment by joe.wal...@gmail.com on 23 May 2007 at 10:08

• Changed state: Fixed

[GoogleCodeExporter]

Very nice.  And I learned yet something more about Java generics today!

Original comment by david.s...@gmail.com on 24 May 2007 at 4:05

[GoogleCodeExporter]

Actually, I have to recant.  Using the compiler in Eclipse 3.3 RC1, 
AllOfTest.java
still has nine warnings, all of them of the type "Type safety
: A generic array of Matcher<FactoryMethod> is created for a varargs
parameter".  So only one of my three concerns was addressed in the most recent 
check-in.

Which compiler are you using?

Original comment by david.s...@gmail.com on 25 May 2007 at 2:24

[GoogleCodeExporter]

I don't think there's any way round that if you have a varargs function with 
generic
parameters.

Original comment by nat.pr...@gmail.com on 25 May 2007 at 2:34