Re: RFC: Dropping Namespace

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