Quoting Stanislav Malyshev <[EMAIL PROTECTED]>:
Except that it makes it unclear what happens in _other_ files, which is
In other files you specify what happens to other files.
even worse. Once you include the file above, any other file in the
Test:: namespace that throws an Exception will throw
Test::Exception, not Exception, even if it doesn't import
Test::Exception.
I'm afraid I don't understand. Regardless of what you include where,
the name resolution for the file is defined by the code and imports
in this file. Since that file does not define test::exception, it
would not influence resolution of any file it is included in.
This isn't true with the current implementation. Consider these four files:
test_exception.php:
-------------------
<?php
namespace Test;
class Exception extends ::Exception {
}
1.php:
------
<?php
namespace Test;
import Test::Exception;
throw new Exception();
2.php:
------
<?php
namespace Test;
throw new Exception();
And finally the main file, say 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";
}
If I run parent.php as written above, I see this:
Exception
Test::Exception
... which is correct as far as it goes, there are no side effects.
However, if I flip the include order, including 1.php before 2.php,
then I get this:
Test::Exception
Test::Exception
This is the side effect I'm talking about. Because 1.php causes
test_exception.php to be loaded, defining Test::Exception, it doesn't
matter that 2.php doesn't import Test::Exception - I'm in the Test::
namespace, and Test::Exception exists, so it's used.
I think it makes much more sense to import classes that are
_outside_ the current namespace. Having to import pieces of your
own namespace makes namespaces less useful and intuitive.
Import is just a way to write names shorter. Thus, you can employ it
to achieve different goals.
This is true. The goal I am looking at is making sure that when I use
a namespace I have full control over the things inside my namespace.
The way things work right now I either need to list every single class
in my namespace in every file of that namespace - which is going to be
a bit burdensome, and seems like a discouragement from using
namespaces - or I am at the mercy of PHP adding a new class that might
suddenly take the place of one of my namespace classes. Or presumably
someone who used my code could include a different librry that
suddenly overrode one of my classes with a global class.
I understand the argument that namespaces should require minimal
change to other code, but I think that PHP should encourage people to
think a little bit when putting "namespace Foo" at the top of a file.
That should really mean, in my opinion, that everything in that file
is relative to that namespace by default.
It's not hard to then import the global bit you want.
Think about how variable scope works in PHP. The way I am proposing
namespaces to work, they would match scope. You would have:
$GLOBALS => :: - if you want to reference something from global
scope without aliasing it, you can reference it explicitly
global $variable => this is like import, but import lets you alias the
name as well, for using things from global scope but making them look
like they are local
Everything else is in the local scope.
I don't have a grand theory of why variable scope and class scope
should match, but it seems reasonable.
The main thing is that I think that the sort of people who are going
to want to use namespaces are going to want namespaces to be as
self-contained as possible, and that means explicitly importing
external bits, not internal bits.
Sincerely,
-chuck
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
