Deprecate the Is matcher, for eventual deletion

[npryce]

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

[npathai]

@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));

[npryce]

Yes. This issue is for the deprecation. Deletion is another issue.

On Thursday, December 25, 2014, Steve Freeman notifications@github.com
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
#88 (comment)
.

[npryce]

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 notifications@github.com
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
#88 (comment)
.

[npathai]

@npryce Aha now I got it. Thanks.

[CC007]

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.