Front page | perl.datetime |
Postings from January 2003
On Thu, 9 Jan 2003, Dave Rolsky wrote: > 2. Use the DateTime:: namespace. The modules@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@visi.comThread Previous | Thread Next