Hi!
My point is that for this code:
<?php
Classname::Method();
?>
The proposal does not solve the name conflict. If no one rewrites their
Right, 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 to
If 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 without
If 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
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
