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 -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
