Увидел статью о namespace и решил поделиться опытом перевода существующих проектов на namespace.
В основном статья будет полезна тем, кто еще не использует namespace, но задумывается над переписыванием существующего кода.

Я переводил на namespace несколько своих проектов, которые были взаимосвязаны между собой. Проекты не слишком большие и весь переход я сделал за выходные.

Сам по себе переход не представляет особых проблем, ниже я описал последовательность необходимых действий, которые в большинстве своем представляют собой рутину и имеется возможность автоматизации большей части работ… но как говорится дъявол кроется в деталях.

• Отмена 1000-лимита на запрос в хранилище для count и offset. Такие безлимитные запросы будут теперь исполняться до получения результата, или выкидывать ошибку по таймауту хранилища. Я сам слегка потестировал — есть небольшие тормоза на средней базе в пару миллионов записей при смещении в миллион (порядка пары-тройки секунд задержка), однако вполне годно. Хотя, судя по коду SDK, максимальный лимит все же есть, равный 2^31 — 1.
• Новое Namespaces API для Java и Python, которое позволяет создавать «коммунальные» (multi-tenancy) приложения без особых модификаций уже существующего кода.
• Замена сервиса картинок на высокопроизводительное решение, основанное на picasa, что позволит делать превьюшки картинок (crop и/или resize), фактически без использования ваших ресурсов (только трафик) в добавлении к предыдущим умениям Image API.
• Пользовательские страницы для системных ошибок — over quota, DoS, timeout и прочих.
• В Java добавлено Capabilities API, по аналогии с Питоном, а также java-приложения научились понимать конфиги в yaml-формате.
• Многие фиксированные квоты бесплатных приложений увеличились до уровня платных, подробнее.
• Blobstore API теперь поддерживает Content-Range заголовок.

Полные списки изменений:
— Release Notes: Python
— Release Notes: Java
— Revision History

Рекомендую ознакомиться с php internals: endnamespacediscussion

После очередной дискуссии в IRC принято решение использовать символ \ в качестве разделителя в пространствах имен в PHP. Патч готовится, и неизвестно войдет ли он в PHP 5.3 или нет.

С аргументацией можно ознакомиться здесь или здесь

Основная проблема при использовании :: в качестве разделителя по мнению разработчиков заключается в том, что понять что происходит в строке кода
Foo::bar();

станет трудно (это вызов статического метода bar() из класса Foo или вызов функции bar() из пространства имен Foo?). Дополнительным ограничением также является сам интепретатор PHP, который не сможет отличить разрешение имени от вызова статического метода. Избавиться от такой неоднозначности предполагается при помощи символа \.

В последних версиях PHP появились namespace'ы — пространства имен.

У них есть очевидные преимущества:
— помогают сократить названия классов;
— позволяют избежать конфликтов имен;
— помогают лучше структурировать классы.

Но, помимо этого, есть еще преимущество, на которое не так часто обращают внимание: namespace'ы помогают разработчику видеть зависимости того или иного класс, причем это не приводит к какому-либо оверхеду. Поясню.

Помните, как в PHP4 мы писали перед объявлением класса:
require_once «MyClassParent.php»;
require_once «MyClassDependency.php»;

Потом пришел PHP5, появился __autoload() и spl_autoload_register() — мы убрали безусловные подключения файлов и вместе с ними оверхед. Все хорошо, да вот только теперь не так очевидно стало, какие же другие классы/файлы нужны для нашего класса, чтобы он нормально функционировал.

И тут — появляется батут php-5.3. Теперь, без лишнего оверхеда мы можем, и даже не только можем, но и в определенных случаях должны — указывать зависимости нашего класса:
use myns:: MyClassParent;
use anotherns:: MyClassDependency;

Отметим, что при использовании use не происходит подключения файлов с классами.
Теперь, как говорится, и программисты волки сыты, и харды овцы целы.

Пространство имён (namespace/package) знакомо java и c# программистам, теперь доступно и в php. Нужно оно для того, что-бы не писать длинные перефиксы к названиям классов, как сейчас делается в Zend, PEAR и других библиотеках и платформах для совместимости.
Вместо этого классы, функции, интерфейсы (абстрактные классы) и константы могут быть объединены в одно пространство имён. Глобальные переменные в это пространство не входят.

Простой пример

Определяется пространство ключевым словом namespace
//определяем класс в пространстве
namespace MyCMS::Core;
class System{}
Использование этого класса в третьих библиотеках осуществляется ключевым словом use
require_once('mycms/core.php');
use MyCMS::Core::System; //импортируем только заданный класс
$objSystem=new System;

Прочитав заметку об использовании пространств имён в Javascript коде мне захотелось поделиться подходом, который использую я. Он изобретён не мной, конечно, но, возможно кто-то о нём не знает. Этот подход отличается от предложенных в той статье тем, что позволяет кроме функций и данных видимых снаружи, также определять данные и функции локальные для пространства имен и невидимые снаружи.