[LRUG] Comparable Null Objects

[Duncan Stuart]

@sleepyfox, you (or someone else above?) are correct that this ordering is
probably only a presentational concern.

Since you asked, the stories might be something like this: (though please
let's not get into a critique of how best to express user stories).

Background:
* Event curators manage a collection of other people's events
* Some events are one-offs, some are recurring but intermittent, others
repeat regularly (e.g. monthly)
* Regularly repeating events are unreliable: not guaranteed to happen in
the same week every month, and may not happen at all some months.
* Future dates often aren't published until quite close to the event.

Stories:

AS AN event curator
SO THAT I can judge how likely it is that a future date for a recurring
event has been published
I WANT to see the next expected date of recurring events
Detail:
* For regularly recurring events this can be set automatically
* For intermittent events this can be set manually, but otherwise may be
missing

AS AN event curator
SO THAT I can prioritise the events for which I need to confirm future dates
I WANT to see a daily report of events which have no future dates
Detail:
* This event list should be ordered by expected_date (i.e. next expected
first, which is priority order)
* Events with no expected_date should be considered highest priority

On 18 July 2015 at 11:54, Sleepyfox <sleepyfox at gmail.com> wrote:

> Thinking out loud:
>
> Another use of NullDate with sorting might be to place them 'now', as
> if they are placed at the beginning (of time) or end then they may
> never get seen by the user.
>
> On the other hand, placing them in a totally separate piece of the UI
> may be a better course of action, in which case null dates should be
> filtered and never appear in the sorted chronological view.
>
> I'm guessing that there are requirements that are not being expressed
> here: why is it that some events do not have a date? Is it that they
> are ongoing or repeating events? Or is it that they are awaiting
> scheduling? The business meaning behind not having a date will dictate
> how you wish to deal with them.
>
> Personally I would feel uncomfortable mixing in 'date-less events'
> with the general 'date-ful' events; whenever I see something like this
> there is generally a more elegant (domain) solution that makes all the
> complexity go away...
>
> Fox
> --
> "What does the @sleepyfox say?"
>
>
> On 17 July 2015 at 14:18, Andrew Premdas <apremdas at gmail.com> wrote:
> > The use of a NullDate is not incompatible with something wanting to sort
> > Events in a particular way. If we think about how NullDate's should be
> > sorted we can see a very limited number of possibilities
> >
> > - place at the end
> > - place at the beggining
> >
> > So our NullDate could support a convention when implementing comparable
> to
> > make one of these choices and perhaps allow configuration to choose the
> > other. This would allow Events (and lots of other stuff) to use
> NullDates,
> > and allow Event collections to control how Date's effect the ordering.
> >
> > I wonder should this functionality actually be in Date?
> >
> > On 17 July 2015 at 11:51, James Mead <james at floehopper.org> wrote:
> >>
> >> I just came across the undocumented Date::Infinity class [1] which
> >> might be of some relevance to this thread.
> >>
> >> [1]:
> >>
> https://github.com/ruby/ruby/blob/c8b3f1b470e343e7408ab5883f046b1056d94ccc/ext/date/lib/date.rb#L7..L58
> >>
> >> On 17 July 2015 at 00:53, Paul Makepeace <paulm at paulm.com> wrote:
> >> > On Thu, Jul 16, 2015 at 3:24 PM, Stephen Best <bestie at gmail.com>
> wrote:
> >> >>
> >> >> events.sort_by { |e|
> >> >>   e.date { heat_death_of_the_universe }
> >> >> }
> >> >>
> >> >
> >> > This to me is the clearest of the proposals (Tom's role idea is cool
> >> > too).
> >> >
> >> > For a null object you could also use... nil
> >> >
> >> >   events.sort_by { |e|
> >> >     e.date || date_that_sorts_at_the_end  # (named to be clearer about
> >> > intent)
> >> >   }
> >> >
> >> > The whole discussion has been really interesting!
> >> >
> >> > Paul
> >> > _______________________________________________
> >> > Chat mailing list
> >> > Chat at lists.lrug.org
> >> > Archives: http://lists.lrug.org/pipermail/chat-lrug.org
> >> > Manage your subscription:
> >> > http://lists.lrug.org/options.cgi/chat-lrug.org
> >> > List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
> >> _______________________________________________
> >> Chat mailing list
> >> Chat at lists.lrug.org
> >> Archives: http://lists.lrug.org/pipermail/chat-lrug.org
> >> Manage your subscription:
> http://lists.lrug.org/options.cgi/chat-lrug.org
> >> List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
> >
> >
> >
> >
> > --
> > ------------------------
> > Andrew Premdas
> > blog.andrew.premdas.org
> >
> > _______________________________________________
> > Chat mailing list
> > Chat at lists.lrug.org
> > Archives: http://lists.lrug.org/pipermail/chat-lrug.org
> > Manage your subscription:
> http://lists.lrug.org/options.cgi/chat-lrug.org
> > List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
> >
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> Archives: http://lists.lrug.org/pipermail/chat-lrug.org
> Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org
> List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20150718/e95dbd8e/attachment-0003.html>