[phobos] datetime review

[Jonathan M Davis]

On Thursday, October 14, 2010 13:13:27 Steve Schveighoffer wrote:
> OK, read through all the datetime messages now, responding to these points
> below:
> 
> 
> 
> ----- Original Message ----
> 
> > From: Jonathan M Davis <jmdavisProg at gmx.com>
> > To: phobos at puremagic.com
> > Sent: Tue, October 12, 2010 1:58:15 PM
> > Subject: Re: [phobos] datetime review
> > 
> > On Tuesday, October 12, 2010 07:21:07 Andrei Alexandrescu wrote:
> > >  Speaking of all this, Jonathan, what's your plan right now? There's
> > >  been some points raised here and there by people, you replied "this
> > >  is a good suggestion but there are cons as well", so I'm not sure
> > >  whether you plan to keep the submission as is or operate changes to
> > >  it. In the latter case, I'm unclear on what changes you have decided
> > >  to make.
> > > 
> > > One  other thing - it might be useful to take this entire review
> > > process to  digitalmars.D. Is everyone comfortable with that?
> > 
> > I have been making  various of the suggested changes, and I hope to have
> > an updated version with  most or all of them by this weekend at the
> > latest, but
> >
> >I'm
> >
> > not at home at  the moment with the updated code, so I can't say for sure
> > what
> > 
> > all the  changes are that I've made or am making, though I'll give a list
> > when
> >
> >I
> >
> > post  the new code.
> > 
> > I did decide to make changes to reduce the durations to  just Duration
> > (which
> >
> >is
> >
> > basically HNSecDuration) and TickDuration and have  removed most of the
> >
> >addXXX()
> >
> > functions. I'm not entirely happy with result  since dealing with years
> > and months is definitely more awkward in some  cases, but I think that
> > the places where it's a problem are relatively  limited and that it's
> > likely going to be easier for the average  programmer.
> 
> I'm interested to see this.  I originally thought having simply a duration
> in number of hnsecs would be sufficient, but I didn't really hate the way
> you had the different duration types.  It certainly was a novel idea.  The
> only awkward part is when you'd expect normalization.
> 
> FWIW, I think ignoring months/years except for where they are needed is a
> solid way of doing it.  In Tango, the calendar class had an addMonths(Time
> t, int months) which was sufficient for almost all uses.
> 
> 
> IMO, all you lose here is syntax:  not being able to simply do a + b.

What's really annoying is when you want to create a range which iterates over 
time points which are apart by some combination of years, months, and smaller 
units. Before, you could just give the function something like Dur.years(5) + 
Dur.months(1) + Dur.days(2) and it would produce a function which gave you a 
time point 5 years, 1 month, and 2 days after the previous one. But without 
MonthDuration or JointDuration, that becomes much more awkward. I'm still 
ironing out the best way to deal with the function signature for that.

I really do think that I prefer having MonthDuration, HNSecDuration, and 
JointDuration, but as well as it does overall, it's still an abstraction which 
is somewhat leaky, and it seems fairly clear that a lot of programmers would see 
the different duration types and think that it was too confusing and/or 
complicated. Even if it's easy to use, the fact that it isn't necessarily quick 
and easy to understand is still a barrier to using it (which, as I've pointed 
out before is exactly the problem that std.algorithm has: it's actually quite 
easy to use overall, but it's not quick and easy to figure out or understand).

> > I'm currently working on converting TUnit over to use strings  as you
> >
> >suggested,
> >
> > and assuming that nothing particularly wrong with that  pops up, I'll be
> > going
> > 
> > with that. Certainly, having to type stuff like  TUnit.day seems pretty
> > ugly, though I did manage to limite the number of  places where TUnit
> > needed to be
> >
> >used
> >
> > directly by the users of  datetime.
> 
> One of the issues of using enums to parameterize templates is:
> 
> foo(TUnit tu)(long xyz) {...}
> 
> requires instantiating like:
> 
> foo!(TUnit.seconds)(123);
> 
> But can't the compiler just assume you are passing a TUnit value?  i.e. we
> could make this the equivalent of the string version (with the added bonus
> of not requiring silly constraints) if you could call foo like:
> 
> foo!seconds(123);
> 
> Has this been proposed and rejected before?  I can't imagine I'm the first
> to bring this up...

Yeah. I don't know why that isn't the case. The place that it's always annoyed 
me is in switch statements - especially final switch statements. They're all 
guaranteed to be the enum in question and yet you still have to fully qualify 
each enum value every time.

- Jonathan M Davis