Repository navigation
Remove CollectionContainsConstraint #1324
Description
Activity
- added this to the milestone
on Mar 7, 2016 Would the plan be to use SomeItemsConstraint in Has.Member(), Contains.Item() and Does.Contain() instead?
I doubt many people use our constraints directly. Even then, should we deprecate for one release?
Even simpler:
return Has.Some.EqualTo(expected)I think there's a benefit to eliminating any unneeded constraints, since I often find my self searching through and comparing those that work in a similar way. It's a time sink.
The trick would be to deprecate the constructor of the constraint while avoiding deprecating Has.Member(), etc. Perhaps by adding an internal static factory method for use by the syntax elements. Or we could just not worry about it and remove. :-)
- modified the milestone:
on Jun 24, 2016 @rprouse We already discussed this. Shall we move it to Backlog at a low priority?
I say just not worry and remove.
- added a commit that references this issue
on Jun 10, 2017 - changed the title
[-]Remove CollectionContainsConstraint?[/-][+]Remove CollectionContainsConstraint[/+]on Aug 26, 2017
See the note at the bottom of this page.
We could do away with the constraint and have all the syntactic elements generate a SomeItemsConstraint. It would remove one small class and a test class from our codebase.
OTOH, if there are people who actually construct the constraint, it would break their code. There can be other things like this under Constraints, so let's decide on whether to keep such code or remove it.