Live data from Hacker News

Always use [closed, open) intervals

fhur.me

11–20 of 169 posts

Re: Always use [closed, open) intervals

#11

There are convincing cases one can make in favour of half-open intervals (at least in certain circumstances), but this isn’t it. This is just a rambling, absolutist mess.

Why not? The precision one sounds convincing and I don't have any obvious counters

Let's say you want to find accommodation from day x to y, would you rather have [x, y + 1) as the interval in the code?

In other words, I think the blog post lists problems the author has had and in those cases an open-closed interval would have worked better. But one could come up with an opposite case, would that be equally true?

Re: Always use [closed, open) intervals

#12
This is one of those "well, of course!" pieces.

But I've bookmarked it, in case I run into someone who thinks they disagree, in which case I can offload the explanation.

I had a similar incident with colleagues who had discovered the "Default" trait and starting adding defaults to everything, including things that didn't have good defaults, and things where they didn't mean default but actually something quite specific such as "empty". The canonical "don't do that!" blog post didn't exist, so I had to create one.

Re: Always use [closed, open) intervals

#13
post #12

This is one of those "well, of course!" pieces. But I've bookmarked it, in case I run into someone who thinks they disagree, in which case I can offload the explanation. I had a similar incident with colleagues who had discovered the "Default" trait and starting adding defaults to everything, including things that didn't have good defaults, and things where they didn't mean default but actually something quite specif…

So, if I want to book the night from Jan 13th to Jan 14th on AirBNB (which is the very first example given in the post), I should search for "Arrival Jan13th, Departure Jan 13th"?

As with any piece of advice, there are cases where it applies and cases where it does not apply. Or, in other words, someone can claim "Well, of course!" for the opposite advice.

Re: Always use [closed, open) intervals

#14
> Never, ever, ever use [closed, closed] intervals

I’m not really a fan of “never,” or “always” rules, when it comes to programming. I’ve found it’s usually better to have a “make sure to justify deviations from” heuristics.

I usually use [closed..open) ranges (as they are called in Swift), but sometimes, an inclusive range is a lot more appropriate, for expressing an operation (for example, I may express a range as start...end, as opposed to start..

Re: Always use [closed, open) intervals

#15

> Never, ever, ever use [closed, closed] intervals I’m not really a fan of “never,” or “always” rules, when it comes to programming. I’ve found it’s usually better to have a “make sure to justify deviations from” heuristics. I usually use [closed..open) ranges (as they are called in Swift), but sometimes, an inclusive range is a lot more appropriate, for expressing an operation (for example, I may express a range as…

> as opposed to start..This is not just a convenience thing. ..(end+1) is dangerous, if end is the largest representable number.

Re: Always use [closed, open) intervals

#17

There are convincing cases one can make in favour of half-open intervals (at least in certain circumstances), but this isn’t it. This is just a rambling, absolutist mess.

I am more surprised it is about numbers. I found it more important to take care when dealing with date ranges in databases. And SQL "BETWEEN" lures you into using [from, to], which is great way to shoot yourself in foot. So just my 2 cents:

- what are you going to do when you need to split [a,b] into multiple parts, for performance reasons? [a,c], (c,b] ? Can your codebase handle different interval types? Having [a,b) everywhere is simpler

- stuff like 23:59:59.999999999 is code smell, well until database rounds it up, to next day, then it turns into bug

Re: Always use [closed, open) intervals

#18
post #11

Earlier quoted context omitted.

Why not? The precision one sounds convincing and I don't have any obvious counters

Let's say you want to find accommodation from day x to y, would you rather have [x, y + 1) as the interval in the code? In other words, I think the blog post lists problems the author has had and in those cases an open-closed interval would have worked better. But one could come up with an opposite case, would that be equally true?

Of course if datetimes are involved, you need to go up midnight. So you’re back to +1 and a half-open range

Re: Always use [closed, open) intervals

#19
post #11

Earlier quoted context omitted.

Why not? The precision one sounds convincing and I don't have any obvious counters

Let's say you want to find accommodation from day x to y, would you rather have [x, y + 1) as the interval in the code? In other words, I think the blog post lists problems the author has had and in those cases an open-closed interval would have worked better. But one could come up with an opposite case, would that be equally true?

IIRC (bit rusty now) python makes you do exactly [x, y + 1) in code and it pisses me off which is why I did my own trivial end-is-included range for loops.
Post reply on HN