On Thu, 9 Jan 2003, Chris Josephes wrote: > > 2. Use the DateTime:: namespace. The [EMAIL PROTECTED] 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.
Clever, but really confusing when searching CPAN. > > 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. Yep, that's part of my goal. Out with the old, in with the new. > > - 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? I suppose that's possible too. I think the one thing the [EMAIL PROTECTED] cabal dislikes more than a new top-level namespace, is a single-level module name in a new top-level namespace ;) OTOH, if the goal is to provide a comprehensive set of datetime modules, there's an advantage to having part of the suite be _the_ DateTime module. > > -- 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? Actually, Date::ICal stores things internally as julian days and seconds. I like Date::ICal because its a good start for basic date OO stuff and date math, that's all. It happens to also parse the Ical format, which is nice, but hardly a big deal. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/
