Re: namespaces sanity: addition to RFC explaining why Stas'sproposal doesn't work
| From: | Stanislav Malyshev | Date: | Thu, 16 Oct 2008 17:26:16 +0000 |
| Subject: | Re: namespaces sanity: addition to RFC explaining why Stas'sproposal doesn't work | ||
| References: | 1 2 3 4 5 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-41153@lists.php.net to get a copy of this message | ||
Hi!
My point is that for this code: <?php Classname::Method(); ?> The proposal does not solve the name conflict. If no one rewrites theirRight, it does not. So doesn't yours - you need to modify the code in both cases.
code to use Classname->Method(), then no one will be protected from the ambiguity. I am thinking of the case where a user adds a new feature toIf nobody changes existing code then there's no ambiguity by definition. If the code is changed, then of course one needs to change it in the right way, there's no way around that - you always can think of some wrong code that works, well, wrong.
their existing code that uses a 3rd-party library with namespaced functions that accidentally conflict with the user's classes withoutIf you use 3rd party library that has same namespace as yours somebody had screwed up here - either you used namespace that doesn't belong to you or they used namespace that doesn't belong to them. In both cases the fix is un-screw-up the naming.
their knowledge. As third-party libraries become easier to distribute (which both phar and pyrus plan to do), this will become more of an issue.Nobody should put their classes in PEAR namespace unless they are part of PEAR library, thus this scenario - when somebody outside of PEAR has conflict with PEAR functions/classes - is imaginary. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com