[phobos] next release

Steve Schveighoffer schveiguy at yahoo.com
Fri Sep 17 12:10:56 PDT 2010





----- Original Message ----
> From: Jonathan M Davis <jmdavisProg at gmx.com>
> To: phobos at puremagic.com
> Sent: Fri, September 17, 2010 2:43:16 PM
> Subject: Re: [phobos] next release
> 
> On Friday, September 17, 2010 11:08:54 Steve Schveighoffer wrote:
> > I  don't see the point of doing this.  If you just say the Duration is  not
> > templated, and defines a number of ticks, you get a 20,000 year  span.  Is
> > that not enough span?  It just seems like its  unnecessarily complicated. 
> > Now if I want to add two Durations together  and one is in seconds and the
> > other is in milliseconds, I have to  generate a new function because it's
> > templated.  It's trivial to  get the number of seconds from a number of
> > ticks, if that's what you are  interested in.
> 
> Well, if nothing else, I did it that way because it's nice  and generic. The 
>same 
>
> Duration type works with multiple types of time  points, unlike how Boost has 
> duration types which are specific to each of  its time point types.
> 
> The problem with using ticks for a Duration is that  it doesn't work for any 
> units greater than weeks. Because the number of days  in a month is variable, 
>you 
>
> can't convert between months and anything  smaller without a specific date.

Ah, I see.

Yes, in my implementation (on Tango), TimeSpan only dealt with up to days.  It 
did not deal with years or months because those were calendar functions.

Months are very tricky to deal with.  For instance, if a date is 1/30, and one 
wants to add a month, what happens?  You run into weird situations, and I left 
that awkwardness in another module.  The Span type (Duration, whatever) I think 
should be calendar-free.  This allows a very very simple implementation, and can 
be used in areas where you don't need the complexity of calendars (for instance, 
in thread.sleep).

In the calendar class, I had addMonths and addYears (which essentially was 
addMonths(x * 12)) to deal with dates/times.

> So, if 
> you want to be able to have  durations of months or years, you have to have at 

> least 2 duration types -  one which covers months and years and one which 
>covers 
>
> the smaller units  (presumably by being in ticks as you suggest).

No matter what solution you use, there will be some awkwardness.  For example, 
if you wanted to determine how many months were between two dates, d1 and d2, 
how does that work?  Intuitively, you'd do:

d2 - d1

But the type may not have enough information to convert to months.  If you want 
to have a separate months/years type, then you need to have functions like 
monthsBetween(d1, d2) which returns a months type.

I guess I will wait and see what the final API looks like and then see how I 
like it.

-Steve



      


More information about the phobos mailing list