[mplspm]: Picking up the ball

[Chris Josephes]

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
> built.
>
> 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
data?

You wrote a lot, which is good.  I just wanted to comment on the Namespace
stuff and the base class.

--------------------
Christopher Josephes
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.