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

Есть собственный двиг сейчас с переводом проекта на 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

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

Не надо слишком конкретизировать. То была только абстрактная идея, а Вы уже в ней баги ищите =)

use отлично разрешает большинство ситуаций.

Теперь внутри этого класса модели именно этого модуля доступны в простом виде Model\ClassName. То есть он знает "свои" модели. И откуда этот класс не вызывай, все будет работать. PHP разрулит нейспейсы как надо.

Это сообщение отредактировал(а) Arantir - 29.8.2013, 13:18

что значит баги? мне нужно конктретное решение, а не абстракция. Как я прикручу абстракцию к своему проекту? 

И опять же, при чёткой структуре может это и интересно.. Но ведь есть не только "модельная" структура и классы можут располагаться совершенно по иной логике и вызываться по иному..

С неймспейсами все просто. Создается список папок, откуда начинаются корневые неймспейсы
. Переопределяется автолодер, в нем берется директория по первому неймспесу и к ней прилепляется оставшаяся часть всего неймспейса. 
Все. Дальше PHP все сам сделает, он всегда сует в автолодер "fully qualified name" класса. Остается только создавать файлики с именами классов, прописывать им желаемый неймспейс и класть в соответствующую директорию. Все будет грузиться само, как в Java. После этого структура ограничивается лишь фантазией.
В идеале можно даже создать единственный корневой неймспейс Application, соотнести ему корень проекта и не парится.

Есть некая PHP Framework Interoperability Group, которая пытается навести порядок в самодеятельном php программировании, путем навязывания сообществу стандартов программирования.
В частности PSR-0 достаточно удачная попытка  навязать стандарт на неймспейсы и организацию автолода. Во всяком случае, чем мастерить собственный стандарт, лучше присмотреться к чужому, у которого неплохие шансы стать "общепринятым".

вот смотрю и что-то это совсем на бред стало похоже..

Если namespace это тоже самое (ну или почти) что и путь, то не проще ли получить путь файла разложить его как угодно
был /path/to/project/lib/vendor/Doctrine/Common/IsolatedClassLoader.php 
стал  \Doctrine\Common\IsolatedClassLoader

Вот в принципе о чём говорит эта группа и вообще мне кажется весь разговор   

Дело в том, что сначала PHP узнает про класс, а потом ищет его в файле/файлах, а не наоборот - парсит 1оо5оо файлов и создает из них классы.

ну например что-то такое придумать


так как вызов будет осуществлён из последнего подключенного файла то мы всегда будем иметь адрес этого файла

Мне представляется, что в последовательности

последним включенным файлом будет b.php, а не a.php

А так - забавная функция, ее можно пристроить к автоматическому построителю карты отображения классов в скрипты системы. Другого применения придумать пока не удалось.
P.S. Не, нельзя пристроить даже и к этому...
Не знаю, зачем она нужна    

Это сообщение отредактировал(а) ksnk - 30.8.2013, 08:52

трассировка

В общем получается что узнать путь из которого вызван класс можно только через NAMESPACE? но мне кажется есть какая-то функция в PHP

Применение только одно  это получить те пути которые есть в include_path отсортировать удалить повторения и включить в  них новый путь.

Что то такое 

Но этот способ подходит для классов в виде MYCLASS.PHP без namesapce

Для NP которые не повторят файловый путь, лучше всего это массивная карта чем перебор директорий. 

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

C чего возникло желание узнать путь по имени класса? Обычно эта задача уже решена, своеобразно, в слое autoload-функций, почему бы не скопировать оттуда?

ну если считать что "рекомендации" советуют обзывать namespace как и путь, точему бы просто не разложить путь

это как?

Вот так, примерно, у меня сделано

Просто повторить перебор "базовых" каталогов, если он есть. 

Это сообщение отредактировал(а) ksnk - 30.8.2013, 11:03

Есть такая структура приложений по умолчанию. 

app/frontend  --сайт
  modules
     <name>
         controllers
         models
         // cуб модули > N 
         modules
            <name>
  models
  controllers
app/backend  --админка по структуре также как и в  frontend  
app/common  --общая часть

Как лучше из след. 2х вариантов поступить для NP

1
Писать полностью NP от корня например для модуля crud придется задать такой NP app/frontend/modules 
Из плюсов и минусов:
[+] Даст вызов нужных нам модулей по NP из любого приложения.
[-] сделает переносимость модулей без правки namespace не обойтись.

2
Делать NP от текущей базовой папки приложения, например если мы в frontend  то это /app/frontend/ если это модуль crud из первого варианта то базовая директория становится app/frontend/modules/crud
Дальше NP отталкиваются от базовой папки. Что это дает:
[+] Переносимость модулей в любое другую папку приложения, нету привязки жёсткой к пути даже для субмоделй вложеных в друг друга. 
[-] Невозможно вызвать контроллер из другого приложения

Это сообщение отредактировал(а) Sanchezzz - 1.9.2013, 20:09