Hi Derick,
Now, you cannot override existing classes with "use" statement.
However inside a namespace you don't have internal classes and "use"
works just fine.
<?php
namespace Foo;
use myNamespace::Bar as stdClass;
?>
I think it is clear decision.
If you like to override internal classes just write your code in your
own namespace.
Allowing class overriding is possible from technical point of view (it
is disabled on purpose), but it'll give more mess than advantage.
Thanks. Dmitry.
Derick Rethans wrote:
Hei,
now some patches by Greg and Dmitry made it into CVS, some of the things
in my mail have been resolved, however, we still need to come up with a
solution to the 1st and most important issue:
On Tue, 4 Dec 2007, Derick Rethans wrote:
1. As it is impossible to do "use XXX as NativeClass" we get to the
point where we'd have to namespace new internal native classes
otherwise we might introduce BC breaks. AFAIK, we've always said that
PHP reserves the globals space for it's own use (see also:
http://www.php.net/manual/en/userlandnaming.rules.php). In case we do
add new classes (an example could be DateTimeSpan), they should of
course follow the same format as already existing classes in the
extension (DateTime, DateTimeZone). However introducing the new class
DateTimeSpan might break people's code that do things like:
<?php
use myNamespace::DateTimeZone as DateTimeZone;
?>
feature versions of people would then show:
Fatal error: Cannot use myNamespace::DateTimeZone as DomDocument
because the name is already in use.
It would be silly to require to have to do this:
- Create a class PHP::Date::TimeSpan
- In your scripts:
use PHP::Date::TimeSpan
But with the current implementation, this seems to be the only non-BC
breaking solution. If we chose *not* to require this silly namespacing
of internal classes, users instead have to do this:
<?php
use myNamespace::DateTimeZone as myDateTimeZone;
?>
Basically prefixing the classnames... This you can already do just
fine without namespaces.
I know Greg has some ideas with __php__ as recommendation, but I find it
a bit clumsy still. Perhaps Greg can summarize how it will address the
above issue?
regards,
Derick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
