On Thursday 11 November 2010 13:42:37 Dmitry Olshansky wrote: > > I'm afraid that I don't really get what you're trying to do here. A range > > needs to be created from an interval. It really wouldn't make sense to > > do it otherwise. And when you create a range, it needs a delegate which > > generates the time points for that range. So, you create an interval and > > call either fwdRange() or bwdRange() on it to give it the > > range-generating delegate. I happen to have provided some helper > > functions for generating delegates, but there's nothing to stop you from > > creating your own. > > If you have provided them, then it's OK. > What I meant is we have retro(someRange) to go backwards where applicable. > And I do believe you could return range of DateTime's that's > bidirectional ? > Then there is no need to duplicate the std.algorithm/range > functionality, that's all.
None of the ranges in std.datetime are bi-directional, so you can't use retro on them (or any other algorithm which requires bi-directional ranges). It's a side effect of them being generated as you iterate. I considered having bi-directional ranges, but it was just too messy. You'd have to provide two separate generative functions (one for each direction), and in many cases, when iterating over dates, you wouldn't get the same results because many date calculations aren't reversible (the main problem being that months and years don't have the same number of days). > > Are you trying to say that the range should automatically provide _all_ > > possible time points in an interval and then you specifically filter > > them? That's nowhere near as flexible, and in the case of SysTime in > > particular, think about how many time points that is. It has > > hecto-nanosecond (100 ns) precision. That's 10 million time points a > > second. It could get really inefficient to try and filter all of those. > > Also, I'm not sure that filter would work with an infinite range (I'd > > have to check), which would be a huge setback. I really don't get the > > benefit of your suggestion, though I can undkerstand it if it's not > > entirely clear how ranges in std.datetime are supposed to work. > > Not at all, you provide the precision that the user asks for. E.g. if > users want tot iterate by days - no problem iterate by days. > If by hnseconds, well he(or she) knows better ... Right? > The point is we don't need some predefined delegates, just the natural > ones e.g. by secs, hours and so on as with the roll/add methods. That's doable, but it seems far less flexible. For instance, how would you calculate each successive Easter? Or a holiday which always occurred on the Xth day of the week of a particular month? A number of calculations could easily be based on the dates that came before rather than examining each date on its own and determining whether it was one of the ones that you were looking to iterate over. I mean, even iterating over each successive month with that wouldn't work very well. If the first date were 2010-07-31, would 2010-09-30 be one of the dates to iterate over? In order to know one way or the other, you'd need to have state (like what the last date to be iterated over was), and using a filter does not give you state. It seems to me that using a filter could work well in simple cases but that it falls apart in more complex ones. > Well, I'm not saying it's bad/or some such. I, first of all, told you > it's damn good. > Things could be simplified though if you relay some of burden on > std.algorithm/range and such. > That's the main point I couldn't get for the moment. I think that the real concern is whether the ranges in std.datetime can be used with all of the algorithms in std.range and std.algorithm that they're likely to be want to used with. As they stand, they aren't bi-directional, which could be a problem, but I don't see a good way to make them bi-directional, since date calculations aren't always reversible. You also can't swap them at all, but they have a fixed order by their very nature, so I don't see that as being a problem. There could be problems that I'm not seeing though. Regardless, I don't see std.algorithm or std.range as being much help in generating ranges in std.datetime. It might be nice to use retro to produce ranges which iterate into the past, but the lack of reversibility of date calculations makes it so that doesn't work. And in most cases, a delegate which calculates the next date in the range given the previous one is quite straightforward - if it isn't, it's because the calculation itself is complicated, and attempts at using filter and the like won't make the calculation any simpler. - Jonathan M Davis