sense again. But Stas, consider (old dialect bc I need to update locally
sorry):
import nstest::test as whatever;
This works in the global space, right? Now along comes, say, Pierre or
Right.
Derick or Marcus with this class they just have to add to an existing
(non-namespaced) core extension, and the obvious and perfect name for
this class happens to be 'whatever'. I upgrade PHP and suddenly I start
seeing
Right again. The thing is this problem can not be solved. You can not
both put all your classes into global namespace and expect them never to
clash even when you name two of them by the same name. That's like you
would talk in a language where all words would be "marklar" and expect
me to understand you :)
So what we can do is to avoid getting into such problem by using some
rules. I'd propose these rules:
1. Namespace your libraries
2. Do not import the class name into global space, but only library name.
Meaning, if your class is nstest::test, there's nothing wrong with
saying just so, if you are concerned about clashes. That's not worse
than you has nstest_test previously. But if you had PEAR::DB::Connection
and PEAR::DB::Connection::Data and PEAR::DB::Connection::Exception and
PEAR::DB::Query::Term and PEAR::DB::Query::Result, then you could do:
use PEAR::DB as myDB;
use PEAR::DB::Query as myQuery;
and you'd have to do much less work: just myQuery::Term and
myQuery::Result.
Now sure, I can fix that. I can search and replace all my instances of
'whatever' in my code. How is that different from what we had before?
If you insist on putting everything into globals space - it won't be. We
just give you the option of not doing it.
Greg would say I should've namespaced this file, I know... but it's
possible to use import (OK, 'use' now) in the global space, so how are
you going to prevent people from doing that?
I can't. I can only hope they would do it right, I can't force them to
do it right :)
--
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
