namespaces: import name conflicts with defined class

<?php
namespace test;
class Exception {}
$a = new Exception('hi');
?>

The above code works just fine.

Yes there is a concept. import is best used within a namespace. So,
namespace your code and there is no need to import global classes.

Yep, it works if your whole application uses one namespace, but what
if you have a core package that defines some exceptions and another
package, with a different namespace, that wants to use the core
exceptions? Like

namespace App;
class Exception extends Exception { ... }

and in another File:

namespace App::Db;
import App::Exception;
....

This doesn't work. And worse: imagine PEAR would bring a
PEAR::Exception along, PEAR would be my basic framework and i
wouldn't care about ::Exception, i don't even know it's there - i am
using PEAR. In every Script i would like to use PEAR::Exception in a
convenient way i have to write:

<?php
import ::Exception AS WTF;
import PEAR::Exception;
?>
(Nevermind if this example doesn't fit the PEAR-idea, just s/PEAR/
randomFramework/g then)

You think this makes sense?
Or what about this:
pear/Mail_IMAP/IMAP.php (dunno if this file exists):
<?php
namespace PEAR::Mail::IMAP;
import ::Exception AS WTF;
import PEAR::Exception;

class Imap {
...
}

All this seems just wrong to me, sorry. And i fully agree with Markus:

But how to know in advance, e.g. think about other libraries, which
public classes possibly exist? Isn't this problematic then?

Let's say i PEAR would have namespaces and there is a class
PEAR::DB::Mysql, i use this class as:
<?php
import PEAR::DB::Mysql;

class MyDb extends Mysql {
...
}

And surprisingly someday mysqlnd declares a class named "Mysql", that
would break my code even though i explicitly declared that i want
"PEAR::DB::Mysql" not some different Mysql class that comes from some
fancy extension the admin added today.
So, why this behaviour?

regards,
Benjamin

if your exception is so general that it is called exception you can
obviously simply use exception.

Maybe my exception is a generic exception in my framework and
implements some helper functions i need? But the discussion is not
about exceptions, it's about classnames that PHP declares i don't
want to care about, because i put my classes in "namespaces". Maybe i
don't use DOM and i don't know (i don't want to know) that there is a
"XsltProcessor" class, i implemented a xsltprocessor myself, a
generic one ;). So i need to name it GenericXsltProcessor because
luckily currently there is no other class with that name (yet)? Come
on ...
Who knows what classes SPL or some pecl extension will declare some
day, to me this is like a guarantee that future PHP releases, or
extensions, will break applications that use namespaces. Sounds quite
ironic to me.

regards,
Benjamin

The exception example is well an exception. Here you must inherit
exception.
That is simply how PHP works, it is an intended limitation. That
said in
this case you should not use Exception for your own stuff. Name it
after
your library or product, like MyProductException.

Hey, i have an idea, why not use namespaces and call it
MyProduct::Exception and name everything MyProduct::* - this way i
won't get in conflict with global classes, oh wait ...

Right, you might want to have a class DOM because DOM means something
different for your company.

Yep, that's why i call it Company::DomDocument, and hey, everyone
with a different namespace can import it in his file as
"DomDocument", right? That sounds very comfortable to me. sigh

Generally you should do all your stuff in a namespace and do not
import
anything into the global namespace.

You know that import works per File, right? There is no risk that one
accidently tries to catch a MyProduct::Exception if he consciously
used "import MyProduct::Exception;" in his file.

regards,
Benjamin