datetime review part 2 [Update 4]

[Jonathan M Davis]

On Thursday, November 11, 2010 16:31:56 Tomek Sowiński wrote:
> Jonathan M Davis napisał:
> > I don't see any real benefit in splitting a function into two overloads
> > rather than using static ifs in this manner. The resulting source code is
> > likely nearly identical. You only end up with one function to document
> > this way, and in this case the user doesn't necessarily care about what
> > type of duration they're dealing with. If, they want to add or subtract a
> > duration, here's the function to do it. If anything, I think that I tend
> > to favor using static ifs over duplicate functions with different
> > template constraints if there's no real difference in the from the users
> > perspective.
> 
> Fair enough, although it's no excuse for copy-paste programming. It can be
> easily wrung out of duplication with no loss in readability:
> 
>     /+ref+/ Date opOpAssign(string op)(in Duration duration) nothrow
>         if((op == "+" || op == "-") &&
>             (is(Unqual!D == Duration) ||
>              is(Unqual!D == TickDuration)))
>     {
>         static if (is(Unqual!D == Duration))
>              auto hnecs = duration.total!"hnsecs";
>         else
>              auto hnecs = duration.hnsecs;
> 
>         return addDays(convert!("hnsecs",
> "days")(unaryFun!(op~"a")(hnsecs))); }
> 
> The user may not care, but the maintainer does. Not even convinced about
> the former, when writing I often seek introspection in Phobos source.
> Besides, this is the Standard Library, it should hold code of exemplary
> quality.

That would require you to be able to have unary +. I didn't think that that was 
legal. Upon checking it out though, it looks like it is. I don't really have any 
problem with the way that I did it, but I can see where you're coming from. I'll 
look at reducing some of those functions in a manner similar to that.

> BTW, I still think units of time should be an enum, not a string.

No, strings are definitely better. I had an enum originally, and it was unusable 
in comparison. The main problem is that you have to always preface enum values 
with the enum name - either that you create an anonymous enum, but then you've 
got the problem that incredibly common terms such as years and seconds are now 
useless as variable names. The strings were Andrei's suggestion, and I think 
that they're a definite improvement. It's a bit harder to work with them 
internally in some places (such as when dealing with one unit being greater than 
another), but it's definitely a net gain.


> >> Finally, bordering on bikeshed, weekdays' names are long and months' are
> >> short. Having both short and long names for weekdays and months would
> >> solve the inconsistency and satisfy everyone.
> > 
> > I hadn't thought about that. I'll think about it. I'm not sure that it
> > really matters much though. I tend to prefer full names over short names,
> > but that can become tedious when you use them a lot.
> 
> 3-letter shorts, e.g. January-Jan, February-Feb, Monday-Mon, Tuesday-Tue
> are recognized by just about everyone. It makes sense to include both.

Well, I can't really include both long and short names very cleanly in a named 
enum (especially when there's code that relies on the order and value of the 
values). It really should be one or the other, though I'm open to using the 
short names rather than the long names for the days of the week.

> >> Are there any plans for a Calendar interface to allow user
> >> implementations that distinguish business days and holidays?
> > 
> > I'm afraid that I have no clue what you're talking about. I mean, I know
> > what a business day is and what a holiday is, but I'm not sure what you
> > mean by a calendar interface in this context.
> 
> Sorry, was talking QuantLib, I meant something like this:
> http://dsource.org/projects/quantlibd/browser/ql/time/calendars.d
> (copy-pasting sucks, I know;))
> 
> > Are you looking for a way to
> > query whether a particular day is a business day, weekend day, or
> > holiday? That strikes me as being a function rather than an interface
> 
> An interface (or abstract class) makes sense. E.g. I may want to get the
> number of working days between this and this date. It may be implemented
> faster than walking the interval and pecking day by day.
> 
> > and it would
> > be locale-dependent enough that I can't see it making into the standard
> > library.
> 
> Designing the interface and, more importantly, solving how to store the
> holiday information to allow fast interval querying is not
> locale-specific. Plus, it is in common need for business, and it is not
> trivial -- ideal candidate for the standard library. Then everyone can
> write an implementation for their favorite country or stock exchange on
> their own.

I'm certainly not against adding such functionality to std.datetime, but I 
hadn't considered it, and I think that what I have needs to be appropriately 
refined and then included into Phobos before looking at adding major new 
functionality. I would like to add stuff like date recurrence patterns in the 
future, and if there is any commonly useful date/time stuff which isn't too 
localized, adding it to std.datetime could make a lot of sense, but I'd like the 
base done first.

- Jonathan M Davis