On Tue, 24 Jun 2008, Alexey Zakhlestin wrote: > On Tue, Jun 24, 2008 at 6:36 PM, Derick Rethans <[EMAIL PROTECTED]> wrote: > > 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. > > it won't be a serious 'wtf', as on the top of the file, there would be > some kind of > use MySuperLibrary::DateTime;
I know, but 400 lines down in the code you can't really see that. This addition might fix the immediate issue - but it doesn't make life easier for the developers that have to maintain the code. Even less if they're not aware that stuff is namespaced. regards, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
