[LRUG] Comparable Null Objects

[Tom Stuart]

On 16 Jul 2015, at 13:03, Duncan Stuart <dgmstuart at gmail.com> wrote:
> Because ordering on Dates in Ruby requires actual Dates and not Date-like things, forcing us into an undesirable implementation? 

Yes, I think that’s the underlying problem.

However, many of the techniques for “eliminating” nil checks or instance-of checks don’t really eliminate them, only encapsulate them. The condition that drives the decision about which class to instantiate (or whatever) has to go somewhere. So, for me, the principle is about doing those checks sooner, so that the rest of the system can lean on polymorphism — which is just a different kind of conditional that gets hidden from the caller — instead of having to be directly aware of the condition.

For example, you could “eliminate” the checks here by having two different classes of date-ranking object for events with & without dates, and designing their #<=> methods so that the two kinds of object interoperate nicely during a heterogeneous sort, etc. But you’d still need a condition somewhere to decide which of those classes to use for ranking a given event.

So it is a trade-off, and the guiding principle is how tightly you want to contain the information that an event may be missing its date.