Front page | perl.datetime |
Postings from August 2001
Namespace issues
Thread Next
From:
Rich Bowen
Date:
August 6, 2001 20:21
Subject:
Namespace issues
Message ID:
Pine.LNX.4.33.0108062304280.32563-100000@rhiannon.rcbowen.com
One of the issues that I had hoped to discuss on this list was the
issue of namespaces. There are two major ones.
First, there's the Time:: vs Date:: issue. That is, there are Time::
modules, and there are Date:: modules, and there's no consistent
definition of what goes in which. An appeal to modules@perl.org for a
little direction on this matter did not produce a particularly helpful
answer, and so it seems up to the authors of these modules to make
sensible choices.
I'd like to have some discussion as to what people think these
namespaces mean, and then to request that authors respect those
definitions, and, if a particular module is not in the namespace that
it should be, that it migrate to the correct namespace via a
several-month period of adding warnings to modules, asking people to
move to the new version of the module in the new namespace.
The second issue is one of de-cluttering the modules that are already
there. Yes, I know that I'm one of the main culprits, cluttering the
Date:: namespace with all of the things that I've written for my own
mathematical amusements. But I'm also very willing to change, and move
these modules elsewhere.
What I'd like to propose here is a namespace hierarchy where modules
get put in places that reflect their purpose. Something like, perhaps:
Date::Algorithm - Modules that do things like calculate leapyears,
calculate golden numbers, calculate epacts, full moons, and so on. So
Date::Leapyear would become Date::Algorithm::Leapyear, for example.
Date::Calendar - Modules that implement a particular (usually
non-Gregorian) calendar. So Date::Discordian would become
Date::Calendar::Discordian
Date::Holiday - Modules that calculate the date of a particular
holiday. So Date::Easter becomes Date::Holiday::Easter
There are also a variety of things that purport to be the One True
Module that should be the base class for all Date:: and Time::
modules. There are at least 4 of these that I know of. And I wrote one
of them. All of them have shortcomings. These folks need to get
together and compromise on some things, so we can actually have one of
these that doesn't suck, and which people can agree on.
And then there are the standards like Date::Manip and Date::Calc. They
should probably just stay where they are. I think that a certain
amount of duplication is inevitable when there are monolithic modules
like these two which do EVERYTHING. They are great modules. They're
just a little heavy.
On a related note, I'm working on lists of all the Date:: and Time::
modules (yeah, I know, you can just do an ls in your CPAN mirror) and
trying to understand what they all do, where there is overlap, and
where various authors aught to get together and cooperate on some
things. I know, this is like herding cats, but it keeps me off the
streets.
Please let me know what your thoughts are on these things. And let me
know that I'm not just talking to myself on this list.
--
Rich Bowen - rbowen@rcbowen.com
Author - Apache Server Unleashed - http://www.apacheunleashed.com/
Thread Next
-
Namespace issues
by Rich Bowen