On Sunday 10 October 2010 07:45:14 Andrei Alexandrescu wrote: > Again, the action item is to find realistic use cases.
Okay. If all you're doing is adding to a time point, then addYears() and addMonths() works just fine. It's a bit odd to have addYears() and addMonths() but uses durations for all of the other units, but it's likely less confusing than having the separate types MonthDuration and HNSecDuration. Now, it doesn't work as well for generic code to have add functions for months and years but durations for everything else. You have to special case years and months whereas with MonthDuration and HNSecDuration you don't have to as long as you templatize your duration types. With MonthDuration and HNSecDuration, most of the special casing is in the time point and duration types, so the programmer doesn't have to worry about special casing stuff. The really big gain fo being able to do something like Dur.months(5) + Dur.days(2) and have a duration with both months and days is that it makes it a lot easier to do fancy stuff with ranges. You can specify any combination of time units to specify very exact durations between time units. Without durations with months or years, that becomes much more awkward. I'm not sure how likely it is that someone would be interested in iterating over succesive dates which are odd durations apart like 2 months and 7 days though. It may make it easier to do a proper implementation of date recurrence patterns (RFC 2445, I believe), but since that's already going to require a potentially extensive library to make that work, it could likely abstract away any of the difficulties in having a range which iterates over time points which are apart by more eccentric durations. It wouldn't be all that hard to create a function which took the number of years, months, and a duration to generate a range function, and that would be far more awkward than Dur.months(5) + Dur.days(3), but it wouldn't be all that bad, and it would seriously simplify a lot of the rest of std.datetime. Really, the only major case that I can think of is that being able to generate arbitrary durations is useful when dealing with ranges. If you're simply trying to add a duration to a time point, it's not much worse to have to explicitly use addYears and/or addMonths in addition to adding a duration to the time point (a bit annoying perhaps, but not a big deal). Generic code also does better with durations (though we could always keep addTUnit() and that would solve the generic code issue just fine), but I question that that's all that big a deal. Part of me would definitely like to keep MonthDuration, HNSecDuration, and JointDuration as is, but the more I think about it, the more it looks like it wouldn't be all that bad to have to work around their lack, and while using the durations as they are really isn't all that hard, it's going to confuse a fair number of people when they first encounter them. So, I'm beginning to lean towards just simplifying it to HNSecDuration (though I'd rename it as Duration in that case). It's annoying in some cases, but it'll definitely cut down on the learning curve for using the library. Much as auto pretty much saves the day, it's pretty much a guarantee that there are programmers who will want to (or will think that they have to) actually worry about the specific duration types, no matter how good a job I do at making it so that they don't have to worry about it. I know that there are programmers who have worried about that sort of thing with std.algorithm and been scared off by it, when they don't really need to care thanks to auto. - Jonathan M Davis _______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
