I guess this boils down to four choices: 1) give an arbitrary answer 2) give a reasonable answer that may depend on the current time (add both durations to the current time and compare the resulting times) 3) give an answer if it is correct for all times, throw an exception otherwise 4) always throw an exception
The current behavior is (1). I still favor (2), because it never throws an exception. The problem with (3) is that if you write code that compares arbitrary durations, it will work most of the time (e.g. during testing) but will occasionally throw an exception (e.g. once you're in the wild). It also seems more complicated to implement and document, though maybe not by much. Jon ----- Original Message ----- From: "Doug Treder" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: "Jonathan Swartz" <[EMAIL PROTECTED]>; "Dave Rolsky" <[EMAIL PROTECTED]>; "Max Maischein" <[EMAIL PROTECTED]>; "datetime @ perl . org" <[EMAIL PROTECTED]> Sent: Friday, November 14, 2003 4:49 PM Subject: Re: [Fwd: DateTime::Duration comparisions] > The "fuzzy logic" that was being described earlier on the list is more > attractive. There are definitely edge cases where two durations cannot > be compared and should throw exception. But most of the spectrum is > actually comparable, depending on the units being compared: 30 seconds > is always less than 31 seconds, 1 day is always less than 1 month. In > fact just taking the worst case for every unit still leaves most of the > spectrum comparable. You can determine a span of "worst fuzziness" for > each unit (months are fuzzy for at least 3 days, possibly 4) and throw > exceptions if the duration comes within that range. > > -D > > > [EMAIL PROTECTED] wrote: > > >Jonathan Swartz <[EMAIL PROTECTED]> wrote: > > > > > >>Yes, that is technically true. However, it > >> > >> > >is -so- intuitive and > > > > > >>tempting to > >>compare two durations (because other > >> > >> > >mathemetical operators work, and > > > > > >>because you can compare two datetimes), > >> > >> > >that IMO it would be > > > > > >>appropriate to > >>specifically overload those operators to > >> > >> > >throw an error. Or to have > > > > > >>it > >>compare them anchored at the current time. > >> > >> > >Anything but letting it > > > > > >>compare > >>the reference values. > >> > >> > > > >I think Jon has a very astute point here. I > >used to just compare durations without > >thinking. It was only when I started getting > >strange errors that I looked through the > >module and realised there was no comparison > >overloads. > > > >If you look at 'closest' in the old > >Event::Easter you'll see this. Unfortunately > >the tests provided returned the right thing > >when comparing the references. Of course this > >was just a fluke and only allowed the tests > >to pass. > > > >I would prefer to see these overloads die, > >preferably painfully, so that people realise > >they can't overload duration comparissons. > > > >However, at the same time, I'd like to > >implement $dtdur->compare($dtdur2, $basedt) > >which would return the normal -1, 0 or 1 from > >$basedt. If $basedt is not set, then > >DateTime->now is used. > > > >This would mean we could die with > >"DateTime::Duration cannot overload > >comparison operators. For more information > >see perldoc DateTime::Duration. To compare > >durations see the compare method in the same > >document". > > > >Cheers! > >Rick > > > > > > > > > > > >
