Quoting Stanislav Malyshev <[EMAIL PROTECTED]>:
I'm not sure I follow you. If you intend to always use internal one,
why you define the local one? If you sometimes intend to use one and
sometimes another - I propose you a way to ensure the right one is
always used, this without using potentially long full name. I must
be missing something here - can you specify what exactly you want it
to be? You do understand that if you insist on always using
unqualified name, it must work some consistent way, and this way can
not satisfy all possible scenarios because they are contradictory?
Yes. I think that if you use an unqualified name it should always be
relative to the namespace (and importing internal classes into your
namespace lets you use short names for them, avoiding ::Exception).
This unpredictability is I think the worst part of the current
implementation.
There's no "unpredictability" - the behavior is entirely
predictable, you just don't like it :) That's like saying that
function call is unpredictable, because if you don't define the
function it produces an error.
Here is what I mean:
1.php
-----
<?php
namespace Test;
import Test::Exception;
throw new Exception();
2.php
-----
<?php
namespace Test;
throw new Exception();
parent.php
----------
<?php
function __autoload($class) {
include './test_exception.php';
}
try {
include '2.php';
} catch (Exception $e) {
echo get_class($e) . "\n";
}
try {
include '1.php';
} catch (Exception $e) {
echo get_class($e) . "\n";
}
test_exception.php defines Test::Exception.
If you run parent.php as written above, the first exception will be of
type Exception and the 2nd will be of type Test::Exception. However if
you edit parent.php so that 1.php is included before 2.php, then both
exceptions will be of type Test::Exception.
To me, this is unpredictable because include order changes how
otherwise identical code behaves.
I can solve this in my case by always writing import Test::Exception;.
However, if I really want to use the builtin Exception class, it seems
like I _must_ type it as ::Exception every time - which is something
you wanted to avoid as well as I.
Other options I tried:
import Exception;
-> name conflict, which seems correct
import Exception as Error;
-> Fatal error: Import name 'Error' conflicts with defined class in
/Users/chuck/Desktop/php namespaces/2.php on line 4
(this I don't understand)
import ::Exception as Error;
-> parse error (can't import a top-level class name that way)
Therefore, in my mind, in order to write durable code that will not
break no matter what other classes other developers define or import,
I should always prefix builtin classes with ::.
Given this, the only difference between how I think things should work
is that I think that, when I have declared a namespace, I should be
able to rely on any short name referring to that namespace or one of
my explicit imports. The key being that _I_ declared that namespace
and the imports and they will affect only that file, so I am
completely in control of what name means what.
The way things currently are, using a shortname means look inside the
namespace, UNLESS there's a builtin class with the same short name and
the namespaced version hasn't been autoloaded yet, or there's an
explicit import...
I really think it's unintuitive that when you declare a namespace
names don't necessarily refer to that namespace. It doesn't match
other languages, either - you always need to import classes/names if
you want to use short names for functionality outside your
namespace/package/etc.
Sincerely,
-chuck
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
