I, as a mere PHP user really suggest you guys stick with DateTime and TimeZone. If it's so core, you won't need to prefix TimeZone. It would feel very natural to me without a DateTime_ prefix. Looking at this with a long term view, I think prefixing it with PHP is a very bad idea. PHP6 is the main milestone here. I assume you all want it mean, lean and above all clean.
I see no problem with DateTime. In fact, that's how Delphi used to call it too, so it's not such a strange idea. If any user out there is clashing with DateTime or TimeZone, let's just hope they read the upgrade guide. As long as no big libraries out there don't use these class names, I'd say go for it, because over 99% of the PHP users will benefit. (By the way, won't this naming problem come back to haunt you guys when we finally do have namespaces? SPL would likely get its own namespace, and Spl::SplFileObject seems rather unfortunate too.) Just my 0.02 - Ron ""Steph Fox"" <[EMAIL PROTECTED]> schreef in bericht news:[EMAIL PROTECTED] > Sorry to be a pain Andi, but... > >>I agree completely. Can't we just call the damn thing DateTime stick it >>into >> RC1 of PHP 5.2, and move on? > > It doesn't entirely resolve the problem. There's another class in there > too. > > in ext/date: > > typedef struct _php_date_obj php_date_obj; > typedef struct _php_timezone_obj php_timezone_obj; > > <blah /> > > static zend_object_value date_object_new_date(zend_class_entry *class_type > TSRMLS_DC); > static zend_object_value date_object_new_timezone(zend_class_entry > *class_type TSRMLS_DC); > > in PEAR::Date: > > class Date > class Date_TimeZone > > Do you really want DateTime_TimeZone in PHP for all time because otherwise > it'll clash with PEAR in PHP 5.2? How many machinations should we be > prepared to go through to avoid doing the obvious thing? > > - Steph > >> Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
