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
Support ranges #2
Comments
Original comment by |
Original comment by
|
Original comment by
|
Original comment by
|
Original comment by |
Original comment by |
Original comment by Attachments: |
Original comment by |
Original comment by |
Original comment by |
Original comment by
|
This is implemented as |
@lundmikkel: I think it can be useful to have the ability to treat them as half-closed, e.g. to make it clear that a sequence of intervals is contiguous. (e.g. "1st of January (inclusive) to 1st February (exclusive), then 1st February (inclusive) to 1st March (exclusive)") The current |
I find that people often get confused about interval endpoint inclusion. For certain interval types, only/mainly one type of endpoint inclusion makes sense. E.g. time intervals are half-open (as with I have previously done an extensive interval collection library, and we found that doing endpoint inclusion explicit was the best help for users. It also makes algorithms, e.g. for overlap or containment, easier since they can be considered more generally. To get back to Another possible approach is the one we took, where the interval is generic and allows for all types of endpoint inclusion, but I haven't looked enough at |
I would definitely be happy with |
Well, perhaps I'm opinionated on this, but I really think I can't really think of any exceptions to this, other than human confusion around whether or not the time is a part of the data in question - but we've eliminated that in NodaTime by having separate types for |
Well, I'd always express a half-open interval as The use case I find compelling is when you're thinking in terms of dates, but you want to have an abutting sequence of date intervals, e.g.
I find it easier to check that intervals are abutting by knowing that the end of one should be the same as the start of the other than to have to add a day. (It would be particularly easy to get leap years wrong here, for example.) |
This improves clarity - the property *could* still be removed if nodatime#2 is resolved to make all date intervals inclusive.
This improves clarity - the property *could* still be removed if nodatime#2 is resolved to make all date intervals inclusive.
This improves clarity - the property *could* still be removed if #2 is resolved to make all date intervals inclusive.
I can't remember the discussion I had with @malcolmr about using different types for this, but possible compromise solution - 3 types:
The current Basically, those who never need to deal with an end-exclusive date interval could just use Thoughts? |
I would seriously only have a I not sure about your example, @jskeet. If you wanted to create a half-open interval, then a factory method could be the solution. If it was for readability, then maybe the ToString/DebuggerDisplay could print month names instead of the specific dates. For instance (for some locale):
|
@lundmikkel: That would assume that every use case for an interval that happens to cover every day of a month is the same. Maybe I've got a set of intervals that is meant to be February 1st to February 28th each year, exactly 28 days... it would be odd for that to show differently in leap years to non-leap-years. However, the fact that everyone else seems to think the use case I'm concerned with is irrelevant does make me want to give in. @malcolmr - apologies for the fact that we'll be wasting a lot of the comparer work you did, if we do indeed make these always-inclusive. |
(as noted in #671, I'd be happier if the inclusivity of the range was a property of the type rather than the instance anyway: it seems less prone to mistakes.) |
@malcolmr: Yup, hence my alternative proposal a few comments ago - but it sounds like Mikkel and Matt are pretty sure that the speculated |
Original issue reported on code.google.com by
jonathan.skeet
on 4 Dec 2009 at 8:09The text was updated successfully, but these errors were encountered: