Re: simple solution to another namespace conundrum?

Derick Rethans 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.

Hi Derick, This is (as Rasmus points out) a hazard of using namespaces, but it need not be a large hazard. I've said this before, but it would be wise to implement a namespace-expansion similar to whitespace-stripping option in php, so that one can convert use statements to namespace names. Of course, a PHP script to do this would be about 25 lines long, so that is an option too, but I would guarantee that if you're finding this wtf to be a problem, there are going to be more problems in the script than just use statements that alias to internal classnames. To be more direct - the "use" statement only applies to the current file, which makes debugging this situation much easier. The real WTF comes into play when you have a static method that resolves to the same name as a namespaced function, something that absolutely must be worked out prior to PHP 5.3's release. I know a few ideas are percolating about on this one from the people I've talked to on and off-list, I am looking forward to the ultimate resolution. Greg