Hacker News Reader

Comment by auggierose | Hacker News Reader

I'd say this can serve as an example where triplication is better than your abstraction. What are these special open-ended items? How do you need to extend comparison to account for them? Etc. Whereas the three cases are perfectly clear and easy to understand.

View on HN

The three cases force every code using ranges to deal with them. Apply this way if thinking many times for multiple concepts and you end up with a spaghetti of multiply nested if statements that's near impossible to analyze for correctness. Because now you have to read all code instead of just a tiny subset.

> What are these special open-ended items? How do you need to extend comparison to account for them?

The whole point of abstraction is to make those decisions once and isolate the complexity in one place instead of having it spread over N places in the code, forcing everybody to solve the same problems again and again.

Do ranges not support a limited set of operations through which the rest of the code can interact with them, instead of manipulating the endpoints directly?

I would think of the range itself as the abstraction, and then it matters less how it's implemented since any potential problems are local to the implementation and cheap-ish to fix.

Yes, this is correct. The range is the abstraction, and then you can choose how to represent it. Not much difference between the three range cases, and the single case with special endpoints, except that the three cases are more general, as no special values are needed.

Sure you can probably also do it, but this is not the way how the code was originally written. The original ranges present the bounds in their public API, and most code just operated on them.

Then I would say that's the problem. Whatever implementation you leak, the problem is the lack of implementation hiding, not that the implementation looks this way or that way.

But that's still insufficient abstraction and my general point holds.

It does not. It's not about abstraction, but encapsulation.

Hard disagree here. Encapsulation is just one aspect of implementing the abstraction. And I'm not even convinced it is the best way here. Leaving the ranges as simple structures with two public fields, but introducing an "infinity" concept is another way to go. No encapsulation but still abstract (although one may argue this is still encapsulation but at a different level - applied to range bounds instead of whole ranges).

Encapsulation of ranges doesn't actually fully solve the problem, but just moves and isolates the complexity to the private implementation of the range concept (likely a class in OOP). E.g. you want to compute if two ranges overlap - you still have to deal with the complexity of 3 cases in each argument, so total 9 cases.

And hiding the bounds is likely going to be a lot more intrusive on the existing caller code (more refactoring).

Or could use both. ;)

I agree, your point still holds and if anything becomes stronger, because now we've identified a concept at a higher level of abstraction to replace endpoint operations!

>The whole point of abstraction is to make those decisions once and isolate the complexity

The point Sandi Metz is making is that it's often only obvious when you can do this in hindsight.

Lots of things can look abstractions worthy but aren't - including things that are repeated 3 or even 10 times.

When your three cases run into someone else’s two you have six, and it can even get much worse than that. Or an object running into itself and getting nine cases.

Intervals are nice for representing acceptable ranges. Half intervals mean greater/less than. If you stick infinities on the ends, everything likely works. You then expose methods or functions for all your operations. From the outside, you don’t have to care if it’s a half interval or not (unless that is what you’re particularly checking). On the inside you don’t really, either.

If you’re messing with intervals in a business setting, it’s worth considering if you need multi intervals, non continuous regions.

These are all great for handling uncertainty. Like if you add two weights that have +/- values, you can have the sum have those and be correct. The math is all well defined and rather easy. Wikipedia has good pages on it.

> How do you need to extend comparison to account for them?

The post already says: −∞ < x < ∞ for all numerical x. (And the mathematician in me clarifies that that's all real numerical x.)

I don't remember who said that, but mathematics is all about building abstractions, not about computation. So many times mathematics helped me make code simpler.

The post I am replying to made no assumptions about the domain the order is defined on. If it is over the reals, sure, you can use -∞ and ∞. If it is over the integers, you can use MIN_VALUE and MAX_VALUE, sacrificing some of your domain (which might be a problem, depending on the context), or you can use Option[Int], which comes with performance issues.

Or, you can use a range which is a sum of three/four cases, and not worry about any of that.

> What are these special open-ended items?

> If it is over the reals, sure, you can use -∞ and ∞. If it is over the integers, you can use MIN_VALUE and MAX_VALUE

If you already knew the answer, why did you ask?

Reply on news.ycombinator.com