Re: DateTime::Duration nits...
Ok, this is wack. When I ask the object for delta_days or just days what is it going to give me? Uhh... the same thing it always has? Maybe I'm missing your point. We're talking about overloaded operators returning another duration object. Why would that change the return of methods? -J --
Re: DateTime::Duration nits...
How about a DT::Duration::Set class?
add() pushes a duration object into a DT::D::Set object
_collapse() would call a 'sum' method on a DT::D::Set object
_collapse_to_datetime() would call _collapse (or the 'sum' method
directly) on a DT::D::Set object and add the resulting DT::D object to a
DT object.
And this is easier than $dt-add( months = 1 )-add( days = -2 ) how?
Well DT::D could create one DT::D object for each parameter in it's constructor.
So DT::D-new( months = 1, days = -2 ) would create a DT::D::Set.
If DT understands these sets then your 'syntax sugar' should work with mixed signs.
$dt-add( months = 1, days = -2 );
The down side is it will be a bit complicated to add/subtract these sets.
Although I think this is pretty cool solution:
use DateTime;
my $dt = DateTime-now;
my $dur = sub { $_[0]-add( months = 3 )-subtract( hours = 3 ) };
print $dur-($dt)-datetime;
-J
--
Re: DateTime::Duration nits...
On Mon, 30 Jun 2003, Ben Bennett wrote: The nits: 1) The following doesn't work because add_duration() doesn't return the object, but rather falls through and returns the number of nanoseconds in the final object: -- my $dur = DateTime::Duration-new(months = 3)-add(hours = -3); -- This should be fixed so as to be consistent with DateTime.pm. 2) Having a way to construct this directly would be nice being able to make a duration that you can not directly construct seems odd. Well, maybe. Right now the constructor is really simple, which is good. More functionality is nice, but so is simplicity. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime::Duration nits...
Dave Rolsky wrote:
On Mon, 30 Jun 2003, Ben Bennett wrote:
The nits:
1) The following doesn't work because add_duration() doesn't return
the object, but rather falls through and returns the number of
nanoseconds in the final object:
--
my $dur = DateTime::Duration-new(months = 3)-add(hours = -3);
--
This should be fixed so as to be consistent with DateTime.pm.
2) Having a way to construct this directly would be nice being able
to make a duration that you can not directly construct seems odd.
Well, maybe. Right now the constructor is really simple, which is good.
More functionality is nice, but so is simplicity.
use DateTime;
my $dt = DateTime-now;
my $dur = sub { $_[0]-add( months = 3 )-subtract( hours = 3 ) };
print $dur-($dt)-datetime;
- Flavio S. Glock
Re: DateTime::Duration nits...
On Mon, Jun 30, 2003 at 12:20:43PM -0500, Dave Rolsky wrote:
2) Having a way to construct this directly would be nice being able
to make a duration that you can not directly construct seems odd.
Well, maybe. Right now the constructor is really simple, which is good.
More functionality is nice, but so is simplicity.
Ok, playing with this a bit more (using DateTime 0.13) makes me confused:
--
my $d = DateTime::Duration-new(hours = -3, minutes = 57, seconds = 2);
--
Gives 'minutes' = -123, 'seconds' = -2.
--
my $d = DateTime::Duration-new(hours = 3, minutes = -57, seconds = 2);
--
Gives 'minutes' = -123, 'seconds' = -2.
BUT
--
my $d = DateTime::Duration-new(hours = -3, minutes = -57, seconds = 2);
--
Gives 'minutes' = -237, 'seconds' = -2.
AND
--
my $d = DateTime::Duration-new(hours = 3, minutes = 57, seconds = -2);
--
Gives 'minutes' = -237, 'seconds' = -2.
I am totally mystified. I read If any of the numbers are negative,
the entire duration is negative. as indicating that the individual
signs don't matter.
I think the error is on DT::Duration line 52:
$self-{minutes} = abs( ( $p{hours} * 60 ) + $p{minutes} ) * $self-{sign};
Which should perhaps be:
$self-{minutes} = ( abs( $p{hours} * 60 ) + abs( $p{minutes} ) ) * $self-{sign};
-ben
Re: DateTime::Duration nits...
On Mon, 30 Jun 2003, Flavio S. Glock wrote:
Well, maybe. Right now the constructor is really simple, which is good.
More functionality is nice, but so is simplicity.
use DateTime;
my $dt = DateTime-now;
my $dur = sub { $_[0]-add( months = 3 )-subtract( hours = 3 ) };
print $dur-($dt)-datetime;
Hehe, _you_ might think that's simple but most people don't think in terms
of code references, closures, etc. I think they're great, but it's not
necessarily what I'd suggest for general usage.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Re: DateTime::Duration nits...
On Mon, 30 Jun 2003, Ben Bennett wrote:
I am totally mystified. I read If any of the numbers are negative,
the entire duration is negative. as indicating that the individual
signs don't matter.
I think the error is on DT::Duration line 52:
$self-{minutes} = abs( ( $p{hours} * 60 ) + $p{minutes} ) * $self-{sign};
Which should perhaps be:
$self-{minutes} = ( abs( $p{hours} * 60 ) + abs( $p{minutes} ) ) * $self-{sign};
Yep, looks like a bug.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Re: DateTime::Duration nits...
Why not: $dur1 = new DT::Dur( days = 2 ); $dur2 = new DT::Dur( months = 1 ); $dur3 = $dur1 - $dur2; $dur3-add( days = 3 ); If you add $dur3 to a date, it would add 2 days and subtract a month, then add 3 days again. This is not too difficult to implement. Is it too confusing? - Flavio S. Glock On Mon, Jun 30, 2003 at 12:20:43PM -0500, Dave Rolsky wrote: 2) Having a way to construct this directly would be nice being able to make a duration that you can not directly construct seems odd. Well, maybe. Right now the constructor is really simple, which is good. More functionality is nice, but so is simplicity.
Re: DateTime::Duration nits...
On Tuesday, July 1, 2003 [EMAIL PROTECTED] wrote: Why not: $dur1 = new DT::Dur( days = 2 ); $dur2 = new DT::Dur( months = 1 ); $dur3 = $dur1 - $dur2; $dur3-add( days = 3 ); If you add $dur3 to a date, it would add 2 days and subtract a month, then add 3 days again. This is not too difficult to implement. Is it too confusing? So is $dur2 above an abstracted month? That is, it isn't really resolved into a specific number of days until applied to some real start date? Likewise, how many days long is $dur3 above? It would seem like it holds the real arithmetic in suspense until added to a specific date, yes? On Mon, Jun 30, 2003 at 12:20:43PM -0500, Dave Rolsky wrote: 2) Having a way to construct this directly would be nice being able to make a duration that you can not directly construct seems odd. Well, maybe. Right now the constructor is really simple, which is good. More functionality is nice, but so is simplicity. - Bruce __bruce__van_allen__santa_cruz__ca__
Re: DateTime::Duration nits...
[EMAIL PROTECTED]: Why not: $dur1 = new DT::Dur( days = 2 ); $dur2 = new DT::Dur( months = 1 ); $dur3 = $dur1 - $dur2; $dur3-add( days = 3 ); If you add $dur3 to a date, it would add 2 days and subtract a month, then add 3 days again. I love that this does the right thing. However, I don't see why it cannot be built into the constructor using negative values. The real snag is ordering, but this can be handled properly within the constructor (and adequately documented, not only for the constructor but for the general case). So, yes, the implication is that: $dur = DT::Dur-new(days = 2, months = -1); would indeed behave differently than: $dur = DT::Dur-new(months = -1, days = 2); So long as the behavior (intrinsic to durations) is well documented I think it stands to save lots of typing later. Matt
Re: DateTime::Duration nits...
On Mon, 30 Jun 2003, Matt Sisk wrote: So, yes, the implication is that: $dur = DT::Dur-new(days = 2, months = -1); would indeed behave differently than: $dur = DT::Dur-new(months = -1, days = 2); So long as the behavior (intrinsic to durations) is well documented I think it stands to save lots of typing later. Documented or not, it'll never be intuitive, which makes me think it's a bad idea. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime::Duration nits...
Documented or not, it'll never be intuitive, which makes me think it's a bad idea. This could be a feature of the problem space rather than implementation. :) I'd say it's safe to say 99% of non-temporal geeks underestimate the subtle complexity of the problem...intuitive ends up being inconsistent. Matt (preaching to the choir)
Re: DateTime::Duration nits...
On Mon, 30 Jun 2003, Matt Sisk wrote: Documented or not, it'll never be intuitive, which makes me think it's a bad idea. This could be a feature of the problem space rather than implementation. :) I'd say it's safe to say 99% of non-temporal geeks underestimate the subtle complexity of the problem...intuitive ends up being inconsistent. Right, so given two equally non-intuitive solutions you should choose the simpler one and document the beavhior... -J --
Re: DateTime::Duration nits...
Why not: $dur1 = new DT::Dur( days = 2 ); $dur2 = new DT::Dur( months = 1 ); $dur3 = $dur1 - $dur2; $dur3-add( days = 3 ); If you add $dur3 to a date, it would add 2 days and subtract a month, then add 3 days again. This is not too difficult to implement. Is it too confusing? This gets my vote. It's not as 'cool' as the code-ref solution but it is the behavior I'd expect from user defined data types. -J --
Re: DateTime::Duration nits...
On Mon, 30 Jun 2003, Joshua Hoblitt wrote: Why not: $dur1 = new DT::Dur( days = 2 ); $dur2 = new DT::Dur( months = 1 ); $dur3 = $dur1 - $dur2; $dur3-add( days = 3 ); If you add $dur3 to a date, it would add 2 days and subtract a month, then add 3 days again. This is not too difficult to implement. Is it too confusing? This gets my vote. It's not as 'cool' as the code-ref solution but it is the behavior I'd expect from user defined data types. Ok, this is wack. When I ask the object for delta_days or just days what is it going to give me? Any solution needs to be something that allows the end-user to ask the object what it represents and get a reasonable, useful answer. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
