Closure matcher

[GoogleCodeExporter]

Support for closure matcher:

mock.put(match{ it > 1 }, match{ it in 3..5 }) // closure matchers

Original issue reported on code.google.com by julien.g...@gmail.com on 12 Oct 2008 at 9:50

[GoogleCodeExporter]

Original comment by JohnnyJianHY on 12 Oct 2008 at 12:21

• Changed state: Accepted

[GoogleCodeExporter]

Closure matchers can be implemented by hamcrest matcher, that is, something 
like:
    match{ it == 1 }
can return a instance of org.hamcrest.Matcher, then we can just handle 
org.hamcrest.Matcher. So, I think we should implement both closure matchers and 
hamcrest matchers in same version.

Original comment by JohnnyJianHY on 13 Oct 2008 at 1:27

[GoogleCodeExporter]

Yes you are probably right. However I wasn't expecting that we add a dependency 
on
Hamcrest. Gmock is all about simplicity and asking people to download another 
jar
when they've done the effort of downloading ours is sometimes to much.

So we should define exactly the set of hamcrest style matcher we want and make 
sure
they are consistent with the rest of the API.

I probably had that in mind when I separated both issue, thinking we could have 
the
closure matcher as a first step.

Original comment by julien.g...@gmail.com on 13 Oct 2008 at 7:02

[GoogleCodeExporter]

In the future, we will have to update junit to version 4.5 which already 
depends on 
hamcrest, so users have to download hamcrest even if gmock doesn't depend on it.
I regard defining a set of matchers as reinventing the wheel. What's more, if 
someone has experience on hamcrest matchers, then he can reuse all these 
expreiences 
if we support hamcrest matchers.

Original comment by JohnnyJianHY on 13 Oct 2008 at 9:26

[GoogleCodeExporter]

I think you are probably right. We should come with a way where including this 
third
party library be an option - that would be my preference. And yes we should
definitely not reinvent the wheel.

Original comment by julien.g...@gmail.com on 13 Oct 2008 at 5:38

[GoogleCodeExporter]

So, what's your point? Do you mean that "match{ it == 1 }" should return an 
instance 
of an internal matcher of gmock, instead of org.hamcrest.Matcher, then it can 
be 
independent with hamcrest matchers if users only use closure matchers, right?

Original comment by JohnnyJianHY on 14 Oct 2008 at 1:41

[GoogleCodeExporter]

Yes you right, match should be hamcrest independent. Shouldn't be complicated.

Original comment by julien.g...@gmail.com on 14 Oct 2008 at 6:46

[GoogleCodeExporter]

It is very easy to support hamcrest matchers, should we support it in 0.4?

Original comment by JohnnyJianHY on 17 Oct 2008 at 9:42

[GoogleCodeExporter]

Yes. I can see why not. Issue-20

Original comment by julien.g...@gmail.com on 17 Oct 2008 at 3:26

[GoogleCodeExporter]

Original comment by JohnnyJianHY on 19 Nov 2008 at 6:17

• Changed state: Started

[GoogleCodeExporter]

Original comment by JohnnyJianHY on 19 Nov 2008 at 8:04

• Changed state: Fixed