Deprecate isTrue, isFalse about matcher HOT 6 OPEN

I'm of two minds about this. I see where you're coming from, but I also appreciate the aesthetic value of letting matchers read like sentences where possible—"expect foo is true" reads better than "expect foo true".

If we do decide to do this, I'd want to first improve the output of equals() so that we don't have angle brackets for objects like booleans whose string output we know to be reasonable.

from matcher.

Added to 1.0.0 milestone so we can either decide not to deprecate, or have them removed before the version bump.

This has come up on mailing lists as a source of confusion, IMO having 1 way to solve this problem outweighs the aesthetics of the call.

It definitely can't hurt to have nicer output from equals() in any case 😄

from matcher.

One advantage of isTrue and isFalse is we could do better static analysis, i.e.:

expect/*Inferred: <bool>*/(someFlag, isTrue);

That means if you accidentally type:

expect('clearlyNotTrue', isTrue);

We could potentially lint this. Just an idea.

from matcher.

Hmm, yeah with #37 these could potentially have more utility.

Though if we work out the T|Matcher<T> problem that would exist with expect anyway would we also be able to get the same for expect('notABool', true)?

Do we see a world where we start requiring equals() so we can limit the second argument to Matcher?

from matcher.

Do we see a world where we start requiring equals() so we can limit the second argument to Matcher?

I personally use equals() a lot, but I'm in the substantial minority there—people really like using bare values, and I'd hate to take that away from them. Also, even I use bare values for operators where it helps the match read like a sentence, such as expect(foo, isNot(12)). I'd rather just wait for union types.

from matcher.

I'm of two minds about this. I see where you're coming from, but I also appreciate the aesthetic value of letting matchers read like sentences where possible—"expect foo is true" reads better than "expect foo true".

I think that's more about implicit vs. explicit use of equals(). That's orthogonal to isTrue vs. equals(true), which I think is what this issue is really about.

If we do decide to do this, I'd want to first improve the output of equals() so that we don't have angle brackets for objects like booleans whose string output we know to be reasonable.

FWIW, I much prefer the existing output from equals(). I've been confused by the failure output from isTrue/isFalse/isNull where the expected value is printed without angle brackets but the actual value is printed with them. I then spend time wondering why they're formatted differently (e.g. is the actual value a different type?).

from matcher.