<div dir="ltr"><div class="gmail_extra"><br></div><div class="gmail_extra">I think the key question here is whether the ordering, by date or with undated things last, is something intrinsic and invariant within the domain?</div><div class="gmail_extra"><br></div><div class="gmail_extra">That being the case I then I think `Event` should be comparable. delegating to its date perhaps, and to avoid type checks I'd do something like cast the dates to floats but explicitly (all objects receive `#to_f`). Given this scenario it's a real shame the coercion protocol is so opaque, I would definitely entertain Mark Coleman's suggestion:</div><div class="gmail_extra"><br><div class="gmail_quote">On 16 July 2015 at 16:51, Mark Coleman <span dir="ltr"><<a href="mailto:m@rkcoleman.co.uk" target="_blank">m@rkcoleman.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">How about creating your own class for representing dates</blockquote></div><br>As dates are really dressed up numeric types, with quite a wide interface, it would be quite neat to define an `Event::Date` class which composed of a date primitive and perhaps compares nicely with a far future null date subtype sort of thing.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I suspect however this sorting is not part of the domain and is probably a display concern, in which case all of this is moot. The sorting will be performed by an external object and type checks will be really difficult to avoid. The first thoughts I had around this null object implementation was what about when you need to put the undated events first? or at an arbitrary point in time? or sort by something else entirely?</div><div class="gmail_extra"><br></div><div class="gmail_extra">I'm obsessed with `Hash#fetch` and I think that's a really neat way to encapsulate a nil check conditional such that you don't spray boolean logic everywhere. You could implement something like</div><div class="gmail_extra"><br></div><div class="gmail_extra">class Event</div><div class="gmail_extra">  def date(&block)</div><div class="gmail_extra">    @date || block && block.call</div><div class="gmail_extra">  end</div><div class="gmail_extra">end</div><div class="gmail_extra"><br></div><div class="gmail_extra"># for undated events last</div><div class="gmail_extra">events.sort_by { |e|</div><div class="gmail_extra">  e.date { heat_death_of_the_universe }</div><div class="gmail_extra">}</div><div class="gmail_extra"><br></div><div class="gmail_extra">This would give you the future flexibility to use a null object because you can reimplement date (or override in subclass) such that it calls the block for null objects rather than exclusively the two falsey ones.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div><div class="gmail_signature"><div dir="ltr"><br>Stephen Best<br><div><br></div><div><a href="http://theaudaciouscodeexperiment.com" target="_blank">theaudaciouscodeexperiment.com</a><br><a href="http://github.com/bestie" target="_blank">github.com/bestie</a><br>@thebestie</div></div></div></div>
</div></div>