Re: simple solution to another namespace conundrum?
| From: | Alexey Zakhlestin | Date: | Tue, 24 Jun 2008 14:47:48 +0000 |
| Subject: | Re: simple solution to another namespace conundrum? | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-38580@lists.php.net to get a copy of this message | ||
On Tue, Jun 24, 2008 at 6:36 PM, Derick Rethans <derick@php.net> 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;
--
Alexey Zakhlestin
http://blog.milkfarmsoft.com/