OK, read through all the datetime messages now, responding to these points below:
----- Original Message ---- > From: Jonathan M Davis <[email protected]> > To: [email protected] > 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. > > 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... > I think that I'm applying most of your suggestions (and possibly some of the > suggestions of others), but again, I'd have to look at what I've got at home >to > > remember exactly what changes I've made thus far. I have no problem with >taking > > the review process to digitalmars.D, particularly since there never seems to >be > > many people beyond the Phobos devs themselves who post much on the Phobos >list. > > So, I'll post it there as soon as it's ready. Looking forward to it. -Steve _______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
