DateTime::Set, infinity, and recurrences
Hi All.
DateTime::Set was changed fairly recently in such a way as to
necessitate special handling of infinite datetimes in recurrences. This
isn't such a bad thing, but it does introduce complexity into even the
simplest of recurrences.
From the DateTime::Set docs:
# a 'monthly' recurrence:
$set = DateTime::Set-from_recurrence(
recurrence = sub {
return $_[0] if $_[0]-is_infinite;
return $_[0]-truncate( to = 'month' )-add( months = 1 )
},
span = $date_span1,# optional span
);
The operative line here is return $_[0] if $_[0]-is_infinite. This
line, or something similar, now needs to be added to recurrence
specifications in order to avoid an infinite loop.
My question is why can't this be done automatically? So the following
(consider this to be pseudo-code):
recurrence = sub {
return $_[0]-truncate( to = 'month' )-add( months = 1 )
},
would internally be converted to this:
recurrence = sub {
return $_[0] if $_[0]-is_infinite;
$recurrence(@_);
},
In case that's not clear -- take the intitial sub-ref and wrap the call
in another sub-ref that automatically deals with infinite values.
This would not break backwards compatability and would simplify the
lives of developers seeking simple recurrences.
If a developer really had a need for handling infinite values, then this
wrapping could be explicitely disabled with a parameter in the constructor.
Is this kind of nerfing of the API outweighed by the penalty of to
subroutine calls per iteration?
Thanks,
Matt
Re: DateTime::Set, infinity, and recurrences
Matt Sisk wrote: If a developer really had a need for handling infinite values, then this wrapping could be explicitely disabled with a parameter in the constructor. This was dismissed in a discussion here. (the parameter detect_bounded is commented out in the code) - Flavio S. Glock
Re: DateTime::Set, infinity, and recurrences
On Thu, 24 Jun 2004, Flavio S. Glock wrote: Matt Sisk wrote: If a developer really had a need for handling infinite values, then this wrapping could be explicitely disabled with a parameter in the constructor. This was dismissed in a discussion here. Really, did I dismiss it? I can't remember. But Matt's suggestion seemed reasonable. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime::Set, infinity, and recurrences
Dave Rolsky wrote: On Thu, 24 Jun 2004, Flavio S. Glock wrote: Matt Sisk wrote: If a developer really had a need for handling infinite values, then this wrapping could be explicitely disabled with a parameter in the constructor. This was dismissed in a discussion here. Really, did I dismiss it? I can't remember. But Matt's suggestion seemed reasonable. How about detect_bounded = 1 for the current behaviour? The default would be 0. - Flavio S. Glock
Re: DateTime::Set, infinity, and recurrences
We actually would be changing the current capability, if not the current behavior. Having 'detect_bounded' enabled by default would implement what I discuss but not break anything that already detects bounds on its own. Whether that's the right name or not...it seems okay to me, but other ideas would include 'handle_infinite' (default 1), or 'pass_on_boundaries' (default 0). Matt
Re: DateTime::Set, infinity, and recurrences
On Thu, 24 Jun 2004, Matt Sisk wrote: We actually would be changing the current capability, if not the current behavior. Having 'detect_bounded' enabled by default would implement what I discuss but not break anything that already detects bounds on its own. Whether that's the right name or not...it seems okay to me, but other ideas would include 'handle_infinite' (default 1), or 'pass_on_boundaries' (default 0). handle_infinite sounds ok to me. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime::Set, infinity, and recurrences
This works fine, actually:
use DateTime::Set;
print $DateTime::Set::VERSION, \n;
$months = DateTime::Set-from_recurrence(
recurrence = sub {
return $_[0]-truncate(
to = 'month' )-add( months = 1 )
},
);
print $months-next( DateTime-now )-datetime, \n;
print $months-previous( DateTime-now )-datetime,
\n;
# 0.16
# 2004-07-01T00:00:00
# 2004-06-01T00:00:00
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.
So my vote goes for not changing the parameters...
- Flavio S. Glock
Re: DateTime::Set, infinity, and recurrences
[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
Re: DateTime::Set, infinity, and recurrences
On Thu, 24 Jun 2004, Matt Sisk wrote: 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). The DT::Infinite subclass overrides many of the methods to do nothing (like set(), for example). -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
