Implements arg order is backwards

[willfaught]

Most non-expected-actual functions, like EqualError and Len, put the object to be examined first and the expected value second, but Implements does it in reverse order: type first, then object. This makes it hard to remember.

[matryer]

Please fix this and submit a PR. It would be great if it were consistent.

On 19 Mar 2015, at 17:16, Will Faught notifications@github.com wrote:

Most non-expected-actual functions, like EqualError and Len, put the object to be examined first and the expected value second, but Implements does it in reverse order: type first, then object. This makes it hard to remember.

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

[phemmer]

I would argue that Implements is correct, and Len is backwards.
In most of the functions, the thing being tested against is the second argument, and the thing being tested is the third (and latter) argument(s). Thus in Len, the expected value should be the second argument.

Functions I think need to be fixed: Contains, Len, HTTPBodyContains, HTTPBodyNotContains, NotContains

[willfaught]

Agreed.

[phemmer]

Looks like another backwards method has been added since this issue was created: EqualError

[mvdkleijn]

I believe this issue and related PR can move forward again, but we need to take a look at #399 which makes a fair point.

[willfaught]

I agree with #399, actually. Go has a strong preference for the actual-then-expected order of comparison values. This ticket is just about the order—whatever it may be—being consistent among the funcs.

[willfaught]

Closing due to no activity.

[zzh8829]

request to reopen this for v2, the v1 parameter ordering is very counter intuitive