Ilia Alshanetsky wrote:
> If anything it'll make code complex and intertwined, introduce serious
> scope issue most people have not had to consider up until now and so
> on. It will without a doubt increase language complexity as well, which
> generally translates to a loss in performance.
Am I right to assume that both scoping and performance issues only come
up if we were to implement an import() mechanism? If so, do we really
need import?
If not, then
namespace foo
{
class bar
{
}
}
would be "mangled" at compile-time into foo\bar and should not impose
any performance penalty or scoping issues.
Not having an import() mechanism, however, would mean that the user of
a namespaced package has to use "fully qualified" class names (like
foo\bar, for instance) while the developer of the namespaced package
can (and should) use the "relative" class name. We would still get two
benefits out of this:
- The developer of a package does not need to worry that his class (or
constant, function) names clash with his package's users.
- The developer of a package can shorten the class names inside his
namespaced package significantly.
PHPUnit_Framework_TestCase {}
would become
namespace PHPUnit {
namespace Framework {
class TestCase {}
}
}
Classes inside PHPUnit\Framework could refer to the class as just
TestCase, classes inside PHPUnit as Framework\TestCase, and classes
outside PHPUnit as PHPUnit\Framework\TestCase.
--
Sebastian Bergmann http://sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
