On Mon, 2003-07-14 at 18:19, Joshua Hoblitt wrote:
> > > If Dave OKs this it should be a separate class. Probably DT::Undef.
> >
> > If Dave OKs? Does that ever happen. Unsurprisingly, I don't like this ;)
>
> It's never happened before but I keep hoping... :)
>
> > My experience with SQL tells me that down the path of 3-valued logic lies
> > madness.
>
> There is at least 3 possible states here; real, infinite, and undefined.
> Undefined is the least common case but I'd rather have another possible
> state then returning undef when an object is expected.
>
> > How is returning a weird object that looks sort of like a DateTime clearer
> > than returning false?
>
> I'm not proposing anything more exotic (or much different) then DT::Infinite::*.
Maybe an example will explain why I want to have an undef DateTime:
print $natural->parse_datetime("Feb 29th, this year")
->set( day => 31 )
->add( days => 12)
->datetime;
Of course, this won't always work because:
1. the string "Feb 29th this year" returns undef 75% of the time.
2. We can't always set the day to 31, especially in Feb
If I could return DateTime::Undef when it doesn't parse, and if set()
returned DateTime::Undef if it was out of bounds, then we can turn this
code:
$parsed = $natural->parse_datetime("Feb 29th, this year");
$parsed->set( day => 31 ) if defined($parsed);
$parsed->add(days => 12) if defined($parsed);
print $parsed->datetime if defined($parsed);
into:
print $natural->parse_datetime("Feb 29th, this year")
->set( day => 31 )
->add( days => 12)
->datetime;
Which looks a lot neater.
Cheers!
Rick
