[mplspm]: Picking up the ball
cpj1 at isis.visi.com
Thu Jan 9 18:14:04 CST 2003
On Thu, 9 Jan 2003, Dave Rolsky wrote:
> 2. Use the DateTime:: namespace. The modules at perl.org cabal doesn't
> like it? That's nice. Their buy-in is nice, but lack thereof does
> not prevent success. And in my experience, when presented with
> working code that's being used by a bunch of people, they may accept a
> namespace previously deemed unacceptable.
I don't have any complains about it. There's a chance that DateTime might
cause confusion with Date:: and Time::, which would be a disadvantage.
My only other suggested namespace would be "Horology::" which could be
vague, but still conveys the purpose of the modules.
> Why a new top-level namespace? Well, what's the difference between
> Date:: and Time::? Not much, in most cases. It seems like the
> authors of these modules mostly picked one at random. There are a few
> exceptions, like Time::HiRes, but other than that, it's ridiculous.
> Moreover, the DateTime:: space is empty except for one module, and so
> it won't be cluttered by a million overlapping older modules. So it
> provides a nice psychological benefit of dropping the baggage.
For one thing, using an entirely seperate namespace would help to
completely disassociate these modules from everything else in Date:: or
Time::. Otherwise, we end up making the problem worse by making people
wonder if the modules created by this project are somehow compatable with
what is already out there.
> 3. Start with set of base data objects around which functionality can be
> NOTE: I am not particularly wedded to any of these namespaces, I'm just
> trying to outline the basic functionality I think is needed for a good
> suite of datetime modules. OTOH, I don't want to spend lots of time
> arguing about the damn namespaces!
> - DateTime::Object - Yeah, I know Rich hates class names that describe
> the implementation, so maybe DateTime::Base. I don't care too much. The
> namespace should make it should be obvious that this is the basic building
> block for all datetime functionality in the suite. A good candidate for
> this is the existing Date::ICal code, with a bunch of the Time::Piece
> convenience methods thrown in for good measure. The only thing Date::Ical
> needs is to add support for fractional seconds.
Why not just a DateTime object, like we already have a CGI object?
> -- It must work outside of epoch times. Date::ICal - check!
Can you elaborate more on your preference towards Date::ICal? Are you
saying that you have a preference towards the ISO 8601 time representation
(ie. "20030109T1808") for the internal data structure of the date/time
You wrote a lot, which is good. I just wanted to comment on the Namespace
stuff and the base class.
cpj1 at visi.com
Minneapolis Perl Mongers mailing list
To unsubscribe, send mail to majordomo at pm.org
with "unsubscribe mpls" in the body of the message.
More information about the Mpls-pm