[EMAIL PROTECTED] wrote:
If your recurrence specification is well-behaved, (don't use internals, etc) you don't have to test for infinite-ness.
You only have to use
" return $_[0] if $_[0]->is_infinite; "
if your code can't handle DateTime::Infinite.
As is wont with discussions of infinity, how to handle it can be pretty esoteric. I'd say 99% of the time (can't think of any counter examples) the right way to deal with infinity for next/previous *is* the line "return $_[0] if $_[0]->is_infinite".
But I suppose what you're really saying is that, since DateTime::Infinite is a type of datetime, the short-circuit "return $_[0] if $_[0]->is_infinite" is not necessary if the normal operations you're performing on your datetimes are correctly (i.e. defined) handled by DateTime::Infinite.
Unless I'm missing something, it boils down to efficiency (why pointlessly run a DT::Infinite object through its paces) vs edge cases (probably some case of comparing a DT::Infinite to another DT::Infinite and thereby getting caught in an infinite loop).
So rephrased, you're saying that if the next/previous routines in the recurrence are complicated enough to trip up DT::Infinite comparisons, then they should also be complicated enough to take that into consideration.
I suppose I can buy that. So why have the guard clause in the simple examples presented in the DateTime::Set docs?
Matt
