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", so I don't really consider
it all that usable.
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.
Well, I'm not so sure that moving most of the functionality out to other
modules will make it easier. Yeah, there's a shitload of methods, but at
least people know where to find them. If they're scattered across a bunch
of other modules, that just makes it more confusing.
This is a large change in the API, but isn't that why Dave's leaving the
$VERSION < 1.0?
Not exactly. I just don't really think much of 1.0-ness. I've just been
increment by semi-arbitrary amounts each time. At this point I'd say it's
at least mostly stable.
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 all the 'ymd', 'mdy', 'dmy', 'hms' accessors
],
as => 'DTD';
I definitely don't like the aliasing. Talk about write once, read
nowhere! Do we really want to encourage people to A) construct variations
on a class; and B) name it whatever they feel like?
-dave
/*===================================================
VegGuide.Org www.BookIRead.com
Your guide to all that's veg. My book blog
===================================================*/
