Matching the number of parameters

[Johnny]

The current parameter matchers are not flexible enough for matching the
number of parameters. So I suggest a "matchAll" matcher like:

mock.method(matchAll { it.size() == 2 })
mock.method(matchAll { it[1] == 0 }) // can be more flexible like this
play {
mock.method(1, 2)
mock.method(something, 0, something)
}

Not sure about the method name, and there are some other candidates:
"allMatch", "matchThat"(+1 for this one), "paramsMatch".

And I want to recall the wild card character of stubs for matching any
number of any parameters. I think "*" or "..." should be our best
choice, but something like "stub.method(*)" or "stub.method(...)" cannot
be parsed. Currently, I have got two choices:

1. stub.method(_) // I still think it doesn't look so good
2. stub.method($$) // better, but not good enough (a single "$" cannot
be parsed)

If we decide to support wild card character, I think we should use it
for stubbing instead of a pair of empty parentheses like
"stub.method().returns(0)".

Any thought?

[Julien Gagnet]

Yes! matchAll is a great idea. I don't know why we haven't thought
about it before. I think matchAll work well as it's close to the other
match method.

I am not convince by the wild char. Did you had in mind stubbing only
or for others places? If we use the stub.method() to match anything we
don't really need it. If I had to pick one i would pick the '_' rather
than $$ (which got a negative connotation).

2009/5/27 Johnny <johnny...@gmail.com>:

[Johnny]

I think the method name "matchAll" doesn't have good semantics:

match - the parameter should "match" the matcher
matchAll - "all" parameters should "match" the matcher (?)

What's your opinion?

I meant not only in stubbing but also in any other places, for
consistency. Then we can use wild card in both stubbing and mocking:

mock.method(_).returns(1) // then we don't need to type "matchAll
{ true }"
stub.method(_).returns(1) // consistent with mocking

I agree the negative connotation of '$$', so '_' will be our only
choice.

There is another reason to use wild card for stubbing. Although we can
define explicitly the return value for method calls with different
argument in the version without wild card, say:

stub.clear().returns(0) // all methods named clear will return 0
stub.clear(1).returns(1)

but we cannot get the number of calls of "clear()" only, say:

stub.clear().called // return the number of calls of all clear methods
stub.clear(1).called // return the number of calls of "clear(1)"

We can solve this problem via wild card like:

stub.clear(_).returns(-1) // all methods named clear will return -1
stub.clear().returns(0) // "clear()" will return 0
stub.clear(1).returns(1)
play {...}
stub.clear(_).called // return the number of calls of all clear methods
stub.clear().called // return the number of calls of "clear()"
stub.clear(1).called // return the number of calls of "clear(1)"

在 2009-05-27三的 18:55 +0100，Julien Gagnet写道：