std.dateparse reincarnation

[Jonathan M Davis]

On Friday, October 28, 2011 01:56:40 Stewart Gordon wrote:
> On 26/10/2011 02:44, Jonathan M Davis wrote:
> > I have yet to look over your API in great detail,
> 
> Then don't criticise it for not having a certain feature when you haven't
> read far enough down to discover whether it has that feature.

All I was giving was my impression of it given what I had already seen. I was 
not passing final judgement.

> > but from what I saw, it
> > looked like _all_ alpha characters were considered flags, whereas
> > strftime uses % to distinguish flags from other characters, just like
> > printf and writeln do. I'll look over your API in more detail, but I
> > would consider that a deal breaker if that's what it does.  There may
> > very well be other things that you've done with it which are worth
> > drawing from, but I fully intend to use flags like strftime does.
> 
> Is Phobos meant to be a community effort or a reflection of the preferences
> of one individual?

It is a community effort, but I'm the primary author and maintainer of 
std.datetime and a member of the core Phobos dev team, so I have a definite say 
in the matter. And if I think that a particular formatting scheme is inferior 
for whatever reason, then I'm going to argue against it. And if the core 
Phobos devs are against something, then it's not likely to get into Phobos.

I intend to look over your API in detail this weekend. It may very well be 
that I'll like it better that strftime, but I'm going to have to look into 
both in detail and really look at the pros and cons of each based on how 
std.datetime functions in order to decide what I believe will work best with 
it - whatever that may be. Already, its design is such that it can't use 
strftime to do what it does and will have to have its own implementation 
regardless. I will bring up for discussion whatever I go with in the 
newsgroup, and it may be that we're going to want to have a formal review for 
it given the complexities involved, but we'll have to wait and see.

I'm not saying that your scheme is necessarily inferior. I was merely stating 
that from what I could see at a glance, it appeared to be, since based on its 
initial description, it looks like it can't handle arbitrary strings in a 
format string, which is a major downgrade from strftime. On top of that, I'm 
not interested in straying far from strftime without good reason. We'll see 
what I think of your API once I've examined it in more detail. It may very 
well be that I'll think that it's far and away superior to strftime and we'll 
use it whole-hog. I don't know.

- Jonathan M Davis