On Sunday, January 12, 2003, at 05:30 PM, Dave Rolsky wrote:
[...] keeping in mind that calendar-specific modules will be DateTime::Calendar::X, not DateTime::X [...]I think the "make Gregorian explicit" line of reasoning actually supports moving the various calendars up to second-level namespaces, and filing the various Events and Algorithms at a level below those.
Here's how the "multiple-calendar" namespace might look:
# General-purpose gateway and temporal geometry
DateTime -- Factory methods and class lookup
DateTime::Calendar (POD only?) -- Common interface for calendars
DateTime::Delta -- Difference between two points
DateTime::Set -- A collection of points
DateTime::Span -- A period between two points
DateTime::SpanSet -- A collection of spans
# Our core calendar
DateTime::Gregorian -- Our primary, modern calendar
DateTime::Gregorian::Language -- Internationalization
DateTime::Gregorian::RichParser - Based on Date::Manip et al.
DateTime::Timezone -- Interface to global offset data
The main distribution would presumably only include these basic gateway/geometry modules and the Gregorian calendar, but it leaves room for a proliferation of interoperating modules:
# Calendar algorithms, also expressable as infinite sets
DateTime::Gregorian::LeapYear -- Was DateTime::Algorithm::Leapyear
DateTime::Gregorian::Christmas -- Was DateTime::Event::Christmas
DateTime::Gregorian::Easter -- Not written yet
# Regional variations of the Gregorian calendar get namespaces
DateTime::EasternOrthodox::Christmas
DateTime::US::FourthofJuly -- Was DateTime::Event::FourthofJuly
DateTime::Solar::Equinox -- Find equinox and solstice dates
# Other calendars, with associated algorithms and events
DateTime::Chinese -- Not written yet
DateTime::Chinese::YearAnimal -- Was Date::Chinese
DateTime::Discordian -- Was Date::Discordian
DateTime::Discordian::SaintDays -- Not written yet
DateTime::Hebrew -- Was Locale::Hebrew::Calendar
DateTime::Hebrew::Passover -- Was DateTime::Algorithm::Passover
DateTime::Mayan -- Was Date::Maya
DateTime::Roman -- Not written yet
# Specialized implementations might get their own namespaces
DateTime::Epoch::Posix -- Just a blessed time() value
DateTime::Epoch::HiRes -- Based on Time::HiRes
DateTime::Epoch::TAI64 -- Based on Time::TAI64
DateTime::Epoch::TAI64N -- Based on Time::TAI64N
# Other generic geometry or utility modules filed at top level
DateTime::Handle::SelfUpdate -- Wrapper to allow $dt->hour(17)
DateTime::Sequence -- Ordered set
DateTime::SpanSet::SparseMatrix -- Some kind of efficient storage?
Does this system seem confusing? If you didn't know what "Gregorian" meant, you might feel kind of lost, but otherwise I hope people will find it reasonably intuitive.
Does the organization seem too broad, rather than deep? I'm trying to avoid asking people to put separately-distributed modules below the third level, to avoid 40-character monstrosities like DateTime::Calendar::Chinese::YearAnimal and DateTime-Calendar-Hebrew-Passover-1.0.tar.gz.
Does it invite others to add their own modules? Pushing the main implementation down a level might seem like a meaningless detail, but my hope is that it helps to signal to other module authors that they're not going to be second-class citizens.
-Simon
