Подскажите с пару вопросами. 

Есть собственный двиг сейчас с переводом проекта на namespace возник вопрос.
Cтоит делать для приложений отлетное namespace от двига? 

Целью использования namespace послужили след мотивации с моей стороны.
1) это сократить проверки в autoload  к минимум использовать имя пространства как путь.
2) разделить двиг на отдельное пространство да бы дать возможность использовать те имена классов которые захочется
3) Подключать компоненты симфонии - ZD2 итд... 
4) Пара двигаться дальше использовать все плюшки и пряники 5.4+

Это сообщение отредактировал(а) Sanchezzz - 27.8.2013, 23:46

честно, 4 раза пытался начать это использовать. Но имея движок в тысячи файлов, так и не смог себя убедить что это нужно или актуально 

А вот в очередной раз возвращаться к этому заставляет меня только это утверждение



PS
может в очередной раз меня переубедят ;)

Gold Dragon, я также как и вы брался по несколько раз за это дело  (3) и с каждым разом как г... в прорубе метался туда обратно, у меня хоть и не 1к файлов но за ночь перевел проект, пока в рабочем состояние. 

Вся соль это использовать namespace как путь в autoload



Это сообщение отредактировал(а) Sanchezzz - 28.8.2013, 08:59

Решение, imho, нужное. Оно удобно и разумно, если речь идет о разработке плагина в определенную систему. Бросаем класс в каталог в "пути поиска" файлов проекта и имеем простоту смены версии плагина. 
Опять же, "автоматически", получается непересекающиеся в проекте имена классов. Имя плагина уже входит префиксом-неймспейсом в имя класса.

С другой стороны, если плагин будет использоваться в разных, в том числе и старых, проектах, получается тот еще геморрой.

ksnk,  Да всегда есть трабы, когда нужно внедрить в старый проект, что-то с нового, особенно если процесс эволюции кода проекта ушел далеко вперед. 

Gold Dragon,  Наверняка есть такие места где можно не указывать namespace 
у меня такие места появились, это непосредственно созданные контроллеры и модули, единственное extends нужно прописывать с namespace ну и use какие классы нужно импортировать. 

скорее наоборот  

Так что пока никак не могу себе придумать актуальность.. Что касается autoload, ну может ты и прав, надо поразмыслить... Просто пока не могу осознать это применительно к своим проектам.

PS
а какой смысл вообще использовать  DIRECTORY_SEPARATOR? Юниктовые системы используют / а винде вообще пофиг. Просто ставить слеш и не мудрить?

Если винда или *nix-оси то смысла нету, особенно для винды все ровно какой  путь и какой регистр имен файлов.

DIRECTORY_SEPARATOR зависит от платформы и php как кросплатформенный язык обязан иметь такую константу) 

В общем хочешь используй, хочешь не используй.

перестал использовать, писать много да и строчки длинные   

А что касается автозагрузки классов, то я использую в некоторых случаях простой INI-файл с настройками по типу 


Так что мне кажется снова появился смысл использовать NAMESPACE  только нужен реально работающий код примера ну и понятный 

После прочтения темы уже не могу четко сформулировать какие-то аргументы в пользу неймспейсов. Некоторых, видимо, вполне удовлетворяет и их отсутствие, без особого дискомфорта.

Добавлю тогда просто личный пример. 
Проектик на ранней стадии разработки. Все сделано на неймспейсах. Более 50 классов и более 30 директорий (с учетом вложенных). Используется namespace-based класс-лодер. При всем этом в конфигах прописаны только 5 корневых ("основополагающих") неймспейсов (что-то вроде: контролеры, модели, плагины, сервисы, пользовательские классы). Все классы расположены по путям, соответствующих их неймспейсам и подгружаются, фактически, автоматически, исходя из директорий корневого неймспейса. Любой интересующий разработчика класс находится моментально.
В целом напоминает структуру в Java. Правда, в отличие от нее, в файл можно запихнуть больше одного класса =)

Но лично мне это нравится больше за частую неразбериху в классах. При использовании нейспейсов разработчик косвенно обязуется создать валидный путь к файлу, соответствующий неймспейсу, и назвать файл именем класса.
А то уже был у меня случай, когда в файле типа "класс.php" встретил "Класс_С_Очень_Замутным_Названием"

Namespace. Снижает уровень екстрасенсинга более, чем на 50%!  

"Класс_С_Очень_Замутным_Названием"  ага напоминает стиль ZEND без namespace пример Zend_Search_Lucene_Search_Weight_Boolean где полный путь до файла Zend/Search/Lucene/Search/Weight/Boolean/Zend_Search_Lucene_Search_Weight_Boolean.php

Не не лучше namespace и четко ретуал соблюдать.

Я стараюсь больше 2-3 суб namespace нечего не строить принцип Yii2

Просто не нужно мудрить с большим количеством папок достаточно 2-3;

А нормальный IDE (phpStorm) не устраняет надобность в квалифицированном экстрасенсе? Он и сам сообразит в каком файле какой класс.

Этот явовский принцип "один класс - один файл", применительно к php меня раздражает. Понятно, что для Java это не влияет на эффективность, компилятор скомпилирует, а для php раскидать проект еще в  пару десятков файлов - может сказаться на скорости выполнения, если акселераторы не вкручивать.

  я пользуюсь штормом, вообще не вижу проблем ни с классами ни с функциями. Понятно что это проблемы тех кто до сих пор считает самой лучшей средой разработки блокнот 

Ну нет у меня проблем с названиями  Вот я и считаю, что на данном этап namespace в php как-то не доработан. Кроме как для красивости кода, пока актуальности не вижу.. 

Вотпосидел поразмышлял над автозагрузкой классов.. в конечном итоге получилось ни чем не проще простого INI-файла (и то INI-файл для сложных проектов)

Это была шутка юмора такая   


Зависит от обстоятельств. 
Мультимодульность, структура моделей, иные логические разграничения... Веб-приложения бывают самого разного уровня сложности.
Например:
Module\MyModule\Model\Frontend\Forum\Thread
Module\MyModule\Model\Frontend\Forum\Reply
Module\MyModule\Model\Backend\Account\Account
Module\MyModule\Model\Backend\Account\Settings

Module - подключаемые модули.
MyModule - конкретный модуль.
Model - модели.
Frontend - модели веб приложения.
Backend - модели некого удаленного сервера.
Дальше структура самих моделей.

И вроде бы ничего из этого не выкинешь, так как получится сплошной винегрет. 
Хотя в ином проекте вполне может хватать одноуровых Model, Controller и т.д. без модулей и вложенных неймспейсов.

Да зависит согласен, но это редкий и возможный случай.

Для большого винегрета при частом использование полного пути NP предусмотрены алиасы, что-бы не ###ывало. 

В любом случаи там где используется модель можно предусмотреть метод который будет действовать как фабрика, зачастую модель мы используем непосредственно в контроллере.
Например контроллер знает откуда был вызван из какого модуля, модуль знает свой полный путь. Путь у нас четко повторяет структуру NP как и все вложенные папки.

Дальше создаем в наследуемом классе типа $this->aliasModel('.Frontend.Forum.Thread') , который вернет экземпляр.
Можно для текущего модуля сделать карту  алиасов более короткого имени.
Для вызова моделей их другого модуля тут придется писать уже полный путь алиаса в этом методе или использовать явный вызов по NP и доверить дело autoload

Разработчик уже сам решит как это использовать.

Это сообщение отредактировал(а) Sanchezzz - 29.8.2013, 10:46

что-то малость не понял.. А если я вызываю класс совсем из иного места? Модуль может быть и знает, но вот только путь то получится не корректный