On Wed, 21 Dec 2005, Rick Measham wrote:
So now I come back to DateTime::Decorated that I started back in June to
deafening silence... Unless I get any objections I'll get it ready to go, and
release GPS and WeekConstructor at the same time.
my $DateTimeGPS = DateTime::Decorated( with => 'GPS' );
This means you're sticking a Decorated() function into the DateTime
namespace. Is that intentional? It seems awfully weird.
my $dt = $DateTimeGPS->from_gps( week => 87, second => 23456 );
# Internally, this is a standard DateTime, but the decorator has
# given us a new constructor. Likewise, we now have extra accessors:
print $dt->gps_week; # 87
print $dt->gps_second; # 23456
# and a couple of setters:
$dt->set_gps_week( 88 );
$dt->set_gps_second( 0 );
SIMILARLY:
my $DateTimeWeek = DateTime::Decorated( with => 'WeekConstructor' );
my $dt = $DateTimeWeek->from_week( year => 2005, week => 48 );
AND COMBINING TOO
my $DateTime2 = DateTime::Decorated(with => ['GPS', 'WeekConstructor']);
my $dt = $DateTime2->from_week( year => 2005, week => 48 );
print join('G', $dt->gps_week, $dt->gps_second);
There are a couple disadvantages to this approach:
* Sticking everything in one namespace (DateTime) can lead to name
collisions.
* Looking at the code, it's not clear that some of the methods that appear
to be in that namespace are not available there normally. This makes it
hard to look up docs, for example.
I really wish we could come up with a cleaner way to get the same
functionality. Most importantly, I wouldn't want this to be the _only_
way to do this. So if I want to construct a DateTime object from a year &
week, I shouldn't have to create a new decorated class and do it that way.
-dave
/*===================================================
VegGuide.Org www.BookIRead.com
Your guide to all that's veg. My book blog
===================================================*/
