On Wed, 17 Aug 2005, Rick Measham wrote:
.. to combat this, I looked at Dave's Class::ClassDecorator and released a
proof-of-concept DateTime::Decorated module on this mailing list.
Unfortunately Class::ClassDecorator requires that all the decorating
classes play nice by using NEXT or super,
On Wed, 17 Aug 2005, Rick Measham wrote:
I'm cool with that .. I guess then that each Format module that is 'use'd
would somehow publish methods to the DateTime Class rather than an object?
I'm not sure how this would be technically done using your example code ..
So now if you use a CPAN
While Dave's thinking about date math, can I go back a while ...
.. we were talking about method bload in DT. Since then we seem to have
added a new routing for bringing in a default DateTime::Format module too.
.. to combat this, I looked at Dave's Class::ClassDecorator and released
a
use DateTime::Decorated
with = [
'strftime',
# Yes, pull it out of DT and put it in
# DT:Format:Strftime and DT:Decorated:Strftime
'strptime',
# DT:Decorated:Strptime is an accessor interface to DT:F:Strp
'common',
# This will have
Daisuke Maki wrote:
I actually would rather see an mod_perl-style 'add if requested' style.
use DateTime; # load just the basics
use DateTime::Format qw(strftime strptime hms);
# maybe use DateTime::Format qw(:common) ?
my $dt = DateTime-now;
print $dtd-hms;
At least, I don't
On 8/16/05 8:14 PM, Rick Measham wrote:
I'd like to hear comment on stripping out lots of the methods currently
in DateTime and have them moved to decorator modules -- as this will
allow users to load what they want and only what they want in the way of
functionality.
Fine with me, as long as
I'm cool with that .. I guess then that each Format module that is
'use'd would somehow publish methods to the DateTime Class rather than
an object? I'm not sure how this would be technically done using your
example code ..
Ah, bad naming. I wasn't trying to mix DT::F modules here. How bout
