Closed GoogleCodeExporter closed 8 years ago
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
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
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
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
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
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
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
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
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
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
Original issue reported on code.google.com by
david.s...@gmail.com
on 31 Jan 2007 at 7:48