Re: DateTime Namespace

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

• Re: DateTime Namespace by Matthew Simon Cavalletto
• Re: DateTime Namespace by Abigail
• Re: DateTime Namespace by Dave Rolsky
• Re: DateTime Namespace by Dave Rolsky
• Re: DateTime Namespace by Matthew Simon Cavalletto