Hello, following some discussions on the list (re. multiple namespaces in file) as well as a short discussion on IRC regarding not being able to do "use yeti::xml::DomDocument as DomDocument;" - I do not see any point in having namespaces at all. And my excuses for the somewhat longish mail...
Some arguments: 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. 2. You have to import every class yourself. You can currently not do: use myNamespace::* as *; // or similar syntax I understand why this is not implemented (runtime vs. compile time), but it is a bit of a pain in the ass if you use lots of classes from your own library f.e. 3. We keep bickering over using { } or not, multiple namespaces in a file or not... etc. I understand that people want more flexibility, but also we need a *simple* to explain implementation. With the current implementation I see the following problems here: - You can't stick multiple namespaces in one file - Unlike other constructs in PHP that mark executable blocks, namespaces don't use { }. - The "namespace" keyword at the start of a file is somewhat magic, because it can only appear as first element in your script. 4. What is wrong with simple prefixes in the first place? Both PEAR_*, Zend_*, ezc*, and ezp* are perfectly acceptable markers for different 'namespaces'. We could optionally create a registry on php.net for this to avoid conflicts. With all the above considerations, especially my first point, I still have not heard any good reason why namespaces in the current implementation are actually useful - or what particular case they solve... so I am wondering, are they really useful? I come now to the conclusion that they are not, and for myself (and most likely my work projects) I would have to decide not to go with namespaces, but instead stick with the 3 letter prefixing. Something that I have totally no problem with, as it is nice and easy. 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
