hamcrest
Deprecate the Is matcher, for eventual deletion
The Is matcher doesn't do anything, and so should be deleted.
Factory methods for is should not be added to the domain-specific factory classes introduced as part of #85
@npryce doesn't Is matcher provide a better language like feel to the assert statements?
assertThat(object1, is(equalTo(object2)); sounds much natural than assertThat(object1, equalTo(object2));
Yes. This issue is for the deprecation. Deletion is another issue.
On Thursday, December 25, 2014, Steve Freeman [email protected] wrote:
Probably should be deprecated first. There are lots of people who seem to like it.
— Reply to this email directly or view it on GitHub https://github.com/hamcrest/JavaHamcrest/issues/88#issuecomment-68096966 .
Hamcrest doesn't aim to replicate natural language but implement a compositional notation in which each component of an expression means something. The is matcher goes against that design. It's a historical mistake.
On Friday, December 26, 2014, Narendra Pathai [email protected] wrote:
@npryce https://github.com/npryce doesn't Is matcher provide a better language like feel to the assert statements? assertThat(object1, is(equalTo(object2)); sounds much natural than assertThat(object1, equalTo(object2));
— Reply to this email directly or view it on GitHub https://github.com/hamcrest/JavaHamcrest/issues/88#issuecomment-68126219 .
I like the is(value) shortcut. It's shorter to type and as npryce pointed out is more natural to read. I do agree that is(matcher) is a bit overkill since it doesn't change the matcher outcome compared to the contained matcher, but I also agree that for readability I like the option to use it. Also, its existence doesn't hurt anything and removing it will therefore only be a hassle for end-users since it would be a breaking change.
