-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Interval interface #3661
Comments
This comment was originally written by @seaneagan actually, an "in" matcher (issue #3679) would work better than "contains". expect(x, in(new Interval(0, 100)) |
Removed Type-Defect label. |
I think it's a good idea. It's basically an immutable collection of integers, which can be useful in various cases. Possibly with some Range-specific extra functionality like "overlaps". |
Added Accepted label. |
This comment was originally written by @seaneagan I think Range could extend Interval<int> if there were integer specific functionality desired such as iterability, as intervals are useful for all Comparables (e.g. Date intervals), not just integers: interface Range extends Interval<int>, Iterable<int> {} |
I don't see how an interval would eliminate all four of those matchers. One, yes, but that isn't buying anything. |
This comment was originally written by @seaneagan @gram, here's what I was thinking: instead of: inInclusiveRange(0, 5) you would have: in(new Interval(0, 5, includeMax: true)) alternatively Interval could have named constructors: in(new Interval.inclusive(0, 5)) |
Removed Library-Collections label. |
This comment was originally written by @seaneagan This could also replace the KeyRange class in dart:indexed_db: http://api.dartlang.org/docs/bleeding_edge/dart_indexed_db/KeyRange.html |
We discussed this frequently. Added NotPlanned label. |
This comment was originally written by @seaneagan I added an interval package to pub for this: |
This issue was originally filed by @seaneagan
see https://gist.github.com/2719638
One use case is in dart:unittest...
The "contains" matcher could be extended to match against Intervals.
// e.g.
expect(new Interval(0, 100), contains(x));
Then the following matchers could all be removed:
inInclusiveRange
inExclusiveRange
inOpenClosedRange
inClosedOpenRange
Another sensible name would be "Range".
The text was updated successfully, but these errors were encountered: