Closed roberfi closed 3 months ago
The reason we stuck to sequence instead of iterable is that iterables can be consumed by the iteration, where sequences are not. We are able to make typed assertions about the immutability of them here, thus.
If you want the matchers you're implementing here, I recommend implementing them in a small library that depends on Hamcrest; feel free to use the helper classes and API, but I don't believe we'll take this feature.
Thank you, though! Your PR is appreciated!
Okay. Thank you so much for the explanation. I understand the logic behind the decision. And what about Collection
? It's less restrictive than Sequence
and the only difference between them is that Sequence
is Reversible
while Collection
not. This would make Set
suitable:
Maybe we could leave IsSequenceContainingInOrder
with Sequence
since Collection
order ir not guaranteed.
In either case, we'd be leaving the other names, since those names are part of the API and I am not currently inclined to deprecate them. Adding aliases for them that support collections would be fine, removing the existing ones would not.
I have seen that
Sequence
annotations could be replaced byIterable
making the range of accepted types widerIn order to improve type annotations, I
Sequence
annotations can be replaced byIterable
. This would make all these methods available fordict
,set
orGenerator
, for example, with static type checking.This is backwards compatible and just tests to check methods with dictionary as a
Collection
example where added.