On Fri, 20 Jun 2008, Gregory Beaver wrote: > The user is obviously intentionally creating a "DateTime" class, and > doesn't care about the internal classname in this script. > > The attached patch against PHP_5_3 would fix the issue by eliminating > the check for conflict with CG(class_table) in the global namespace for > internal classes. It however preserves this check for userspace classes > so that (for instance) php-src/tests/Zend/ns_030.phpt does not fail. > The basic idea is that we do have control over the userspace classes we > include, but have no control over the internal classes.
I am not so sure this is a good idea. I mean, for the developer that writes the code it's obvious that his version of DateTime is used. But for a second developer to come back later this could be a great WTF factor a few years down the road - wondering why the DateTime documentation on php.net doesn't match with what the class does. regards, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
