datetime review part 2 [Update 4]
Tomek Sowiński
just at ask.me
Wed Nov 10 15:03:11 PST 2010
Jonathan M Davis napisał:
> Latest: http://is.gd/gSwDv
My 2 cents:
Units of time are represented more naturally by an integer enum (could be anonymous) than a string.
A problem recurring in many methods:
/+ref+/ Date opOpAssign(string op, D)(in D duration) nothrow
if((op == "+" || op == "-") &&
(is(Unqual!D == Duration) ||
is(Unqual!D == TickDuration)))
{
static if(op == "+")
{
static if(is(Unqual!D == Duration))
return addDays(convert!("hnsecs", "days")(duration.total!"hnsecs"));
else static if(is(Unqual!D == TickDuration))
return addDays(convert!("hnsecs", "days")(duration.hnsecs));
}
else
{
static if(is(Unqual!D == Duration))
return addDays(convert!("hnsecs", "days")(-duration.total!"hnsecs"));
else static if(is(Unqual!D == TickDuration))
return addDays(convert!("hnsecs", "days")(-duration.hnsecs));
}
}
If you're static if'ing each statement, it's a good sign the method should be broken up into two overloads.
BTW, what was the problem with returning by ref?
As others pointed out, repetition hurts and hinders understanding repetition hurts and hinders understanding repetition
hurts and hinders understanding repetition hurts and hinders understanding repetition hurts and hinders understanding
repetition hurts and hinders understanding... :)
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.
> After some discussion on the runtime list, it was decided that core.time
> and std.datetime should share their Duration type, so I created time.d as
> a prospective core.time and moved or copied datetime's Duration and any
> other types or functions that it needed to time.d and made it so that
> datetime publically imports time. So, if accepted, time would become
> core.time, and datetime would become std.datetime.
Are there any plans for a Calendar interface to allow user implementations that distinguish business days and holidays?
> Also, since invariants can now be marked pure, I marked some of the
> invariants pure and increased the number of functions marked as pure.
> Unfortunately, due to the fact that many Phobos functions still aren't
> pure (to!() and format() in particular), as well as bug #5191, many
> functions that should be pure, aren't. But we're closer. Also, bug #4867
> continues to prevent SysTime from being able to be immutable, and a couple
> of bugs regarding invariants and templates make it so that a number of
> functions that should return ref this, can't.
Maybe I'm late on the 'pure' changes, but how come all the setters are pure? I mean it modifies the (hidden) argument of
the function, so it shouldn't be, no?
--
Tomek
More information about the Digitalmars-d
mailing list