Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 116
Качество большинства библиотек всегда было не на высоком уровне. Может хоть теперь что-то изменится.
Стоит наверное отметить, что хотя use и находится в том же месте, где раньше был require, он несёт совершенно иной смысл, а именно указывает, какой конкретно класс мы хотим использовать в качестве контроллера в данном неймспейсе.
Привнесенная неймспейсами многословность
Разве?
Zend_Cache_Backend_Memcached vs \Zend\Cache\Backend\Memcached
Второй вариант длиннее на символ)
хотя ИМХО, если бы смотрели в стороне гемов, обозвали бы \Zend\Cache\Backend\Memcached как «will_memcache», «memcahappy», выложили как независимую библиотеку, или ещё как нибудь, и короче было был.
хотя ИМХО, если бы смотрели в стороне гемов, обозвали бы \Zend\Cache\Backend\Memcached как «will_memcache», «memcahappy», выложили как независимую библиотеку, или ещё как нибудь, и короче было был.
А:
и:
$memcached1 = new Zend_Cache_Backend_Memcached;
$memcached2 = new Zend_Cache_Backend_Memcached;
$memcached3 = new Zend_Cache_Backend_Memcached;
и:
use \Zend\Cache\Backend\Memcached;
$memcached1 = new Memcached;
$memcached2 = new Memcached;
$memcached3 = new Memcached;
ага, Зенд назвал класс will_memcache. Пришла Симфония — ну ок, будет у нас sf_will_memcache. Пришел еще десяток разработчиков — получили хаос.
Такой проблемы, например, в Symfony 1.x не было
Зато была проблема того, что ты точно не знал какой именно класс вызовется у тебя.
Все классы Symfony имеют префикс sf. Если знаешь минусы, можешь использовать их как преимущества. А писать километровые имена классов для простоты автолоадера, ИМХО очень «эгоистично» со стороны разработчиков Zend-а.
Согласен, самого напрягали полотна классов ZF. Но по имени класса в ZF, можно было определить к какому компоненту он относится. Теперь есть namespace. :)
Вообще говоря это требования (соглашения?) PEAR. Не только ZF этим страдает. PHPUnit например тоже:
$metaData = new PHPUnit_Extensions_Database_DataSet_DefaultTableMetaData($tableName, $columns);А у ZF есть официальный pear канал? :)
А причём тут есть или нет? Они следуют их соглашению.
Я то думал они следуют этому соглашению.
а кому-то может удобно знать к какому модулю относиться класс
это дело вкуса
это дело вкуса
Согласен, но все равно не удобно. Имея grep я за «пару секунд» узнаю к какому модулю относится класс.
А если, не дай бог, на винде придётся правки вносить? cygwin ставить? :)
На самом деле не для удобства автолоадера это сделано, а для удобства клиентов (разработчиков) — знать где какой класс искать без grep'а и как свои именовать и куда их складывать, чтобы другие с первого взгляда (а не с «парой секунд» и grep'ом) могли понять, что где находится. Автолоадеру проще было бы работать с хэшем 'имя класса' -> 'путь'. Но вот нужно вам в своё приложение включить только часть ZF (как это обычно и бывает, связанность у модулей очень низкая в ZF) — полезете в автолоадер или grep запускать, чтобы узнать какие файлы вам нужно в свой проект скопировать? А если этих файлов с десяток-другой-третий? Но у всех один префикс третьего уровня? Уже «минута» только чтобы их найти, а нужно ещё и скопировать.
На самом деле не для удобства автолоадера это сделано, а для удобства клиентов (разработчиков) — знать где какой класс искать без grep'а и как свои именовать и куда их складывать, чтобы другие с первого взгляда (а не с «парой секунд» и grep'ом) могли понять, что где находится. Автолоадеру проще было бы работать с хэшем 'имя класса' -> 'путь'. Но вот нужно вам в своё приложение включить только часть ZF (как это обычно и бывает, связанность у модулей очень низкая в ZF) — полезете в автолоадер или grep запускать, чтобы узнать какие файлы вам нужно в свой проект скопировать? А если этих файлов с десяток-другой-третий? Но у всех один префикс третьего уровня? Уже «минута» только чтобы их найти, а нужно ещё и скопировать.
Я бы не сказал, что дело вкуса. Дело, скорее, стандартизации, единого подхода. И разграничения ответственностей и инкапсуляции.
Зато сразу понятно, что это за класс, а автоподстановка в любой IDE позволяет набирать имена классов любой длины.
После PHP с Zend Framework-ом и Autoloader-ом трудно привыкнуть к хитросокращённым названиям классов в других фреймворках и языках :)
После PHP с Zend Framework-ом и Autoloader-ом трудно привыкнуть к хитросокращённым названиям классов в других фреймворках и языках :)
Обычно в начале любой книге по программированию написано, что имена переменных должны быть максимально краткими и нести максимальную смысловую нагрузку.
Почему-то никто не пишет
Я конечно утрирую, но смысл тот же
Почему-то никто не пишет
$product_That_Need_To_Be_Added_To_Shopping_Cart = ....;Я конечно утрирую, но смысл тот же
У автозагрузки есть один большой плюс.
Вы можете реализовать в атозагрузчике сборку всех классов в один файл. И потом подключать его одним require. Профит
Вы можете реализовать в атозагрузчике сборку всех классов в один файл. И потом подключать его одним require. Профит
Можно поподробнее? У меня при включенном акселераторе (apc.stat=0) не заметно никакой разницы.
У меня включение одного файла со всеми используемыми классами (примерно 3 Мб) с acp.stat=0 дало ускорение в 2-2.5 раза
Интересно, прибавка приличная. Проект на Симфони2? В автозагрузчике используется is_file (ClassLoader) или isset classmap (MapClassLoader)?
Проект на симфони компонентах. У меня автозагрузка через include_path реализована. Т.е. я явно не занимаюсь поиском файла и проверки на его существование
Понятно, спасибо. У меня на карте с полными путями. Возможно, эффект наблюдается когда очень много кода. Надо будет позже протестировать.
Т.е. у меня реализована след образом. Автолоадер с начала отсеивает классы которые не нужно паковать — это в основном классы моделей Доктрин ибо там свои приколы с парсингом неймпспейсов, далее заменяет константы типа __FILE__ на соотв. пути, добавляет класс в общий файл, чистит apc кеш ибо в противном случае получим бесконечное разбухание файла классов.
При такой схеме, как только во время работы скрипта, требуется класс, которого нет в общем файле классов, он туда добавляется один раз и все.
Но поработать напильником пришлось. Особенно с путями и некоторыми и доктрин моделями
При такой схеме, как только во время работы скрипта, требуется класс, которого нет в общем файле классов, он туда добавляется один раз и все.
Но поработать напильником пришлось. Особенно с путями и некоторыми и доктрин моделями
Интересное решение. А можно реализацию где-нибудь увидеть, например на гитхабе?
pastebin.com/1tHYXudn
Написано на коленке )
Написано на коленке )
Java тут совершенно не причем. Просто PHP движется к enterprise миру, где затраты на написание составляют лишь мизерную часть проекта. Это и не хорошо, и не плохо. Просто нужно понимать где и когда какой фреймворк использовать и использовать ли их вообще.
Вы действительно считаете, что наличие длинных неймспейсов делает ту или иную технологию уровня enterprise?
Я где-то писал только про namespace'ы? Я смотрю в целом на развитие фреймворков и самого языка.
Имхо, двигаться в сторону enterprise — логично. Ибо это даст поддержку крупных и надежных работодателей. Что повысит потенциальные з/п, что повысит престижность языка.
Имхо, двигаться в сторону enterprise — логично. Ибо это даст поддержку крупных и надежных работодателей. Что повысит потенциальные з/п, что повысит престижность языка.
Но для этого надо быть не «как джава», а быть «лучше джава».
А пока только копируются существующие в джава решения, но там они были вызваны особенностями технологии, а в PHP внедряются «потому что это энтерпрайз».
Как бы не вышло так, что PHP и сегмент простых, легких применений потеряет, и до энтерпрайза так и не доберется.
А пока только копируются существующие в джава решения, но там они были вызваны особенностями технологии, а в PHP внедряются «потому что это энтерпрайз».
Как бы не вышло так, что PHP и сегмент простых, легких применений потеряет, и до энтерпрайза так и не доберется.
В чём-то уже лучше. Или ещё? :-/ Одним из главных преимуществ PHP всегда было, имхо, простота развертывания приложения. Тем более возможностей писать «спагетти» никто (пока?) не отнимает.
С ужасом жду тех дней, когда программы на PHP будут компилироваться :)
Простота развертывания? А как же 100500 параметров, задающихся через ini-файлы?
Это уже тюнинг :) Если что я имею в виду Debian-based дистрибутивы Linux и LAMP.
Не всегда это тюнинг. Создателям php долго доказывали, что задание в настройках register globals и magic quotes — зло, и они это поняли. Но почему-то до них не доходит что задание любых настроек в общем случае — зло, ведь от этих настроек зависит работоспособность кода, а значит код перестает быть самодостаточным.
Да, сам язык такой ентерпрайс… Без много поточности, без нативной поддержки utf, без возможности писать что-либо серьезное помимо веб-приложений. Python и Ruby гораздо больший ентерпрайс, но почему-то вот не пытаются копировать в себе Джаву. При этом, есть и JRuby, IronRubym JPython,… То есть эти языки поддерживаются на ентерпрайс уровне без каких-либо синтаксмических или фреймворковых нововведений.
Если вы считаете, что наличие аннотаций, dependency injection, namespaces делает язык ентерпрайсом вы крайне ошибаетесь. Это просто независимые вещи. А вот то, что PHP в гонитве за статусом и пытается стать недоджавой, это печально.
Если вы считаете, что наличие аннотаций, dependency injection, namespaces делает язык ентерпрайсом вы крайне ошибаетесь. Это просто независимые вещи. А вот то, что PHP в гонитве за статусом и пытается стать недоджавой, это печально.
Прочтите мой коммент внимательно. Там только, по сути, про «пытается стать недоджавой» и написано. Только другими словами. Да, наверное, моя ошибка в том, что недостаточно раскрыл мысль.
ЗЫ: Лично я к PHP отношусь очень прохладно и пишу на нем только потому что *пока*что* мой основной заработок идет именно с него. Но это не тема этого обсуждения.
ЗЫ: Лично я к PHP отношусь очень прохладно и пишу на нем только потому что *пока*что* мой основной заработок идет именно с него. Но это не тема этого обсуждения.
Ну тогда ок, почти коллеги )
Мне вот не нравится, что игнорируя все хорошие фишки РНР сообщество пытается создать некую видимость ентерпрайса. Конечно, хорошо, что библиотеки становятся стандартизироваными, чем-то похожими, но плохо, что количество фреймворков до сих пор не дает нужную легкость в разработке.
Мне вот не нравится, что игнорируя все хорошие фишки РНР сообщество пытается создать некую видимость ентерпрайса. Конечно, хорошо, что библиотеки становятся стандартизироваными, чем-то похожими, но плохо, что количество фреймворков до сих пор не дает нужную легкость в разработке.
О. Не один я такой. Заказчики люди консервативные и любят php.
Кроме того заказчики ещё люди рациональные — они учитывают не только стоимость разработки, но и развёртывания, администрирования и поддержки (кода). Почему-то за развёртывание, например, rails приложения на «голом» Линуксе админ-фрилансер или саппорт (в)дс-хостинга берёт больше, чем за развёртывание приложения на PHP(+ZF/Yii/Symfony/...). Меня неоднократно на хабре пытались убедить, что приложение под рельсами развернуть чуть ли не проще чем на голом пхп. Если так, то почему дороже?
куда уж легче чем на lamp :)
Смотря где. С появлением Heroku многие хостеры выпускают свой гем для быстрого развертывания приложения. Например, я использую Webbynode, там развертывание и деплоймент это одна команда и практически без настройки.
Универсального способа нет. С PHP все знают, что переезд с хостинга на хостинг практически без проблем происходит. С rails сложнее вроде как. С heroku же на Webbynode не переедешь правкой одной строчки? Да и ВДС/облака сейчас популярны.
Если в PHP всё так офигенно, то почему для Symfony столь популярен capifony — Capistrano + Symfony capifony.org/. Наверное, потому что деплоймент не столь простой, это раз. И наверное потому, что тулза написана на руби не имеет аналогов на PHP.
Использование Capistrano (я «нативным» пользуюсь) дает лишь удобство задеплоить всё одной командой, да ещё из репов, с версионностью, откатами и миграциями БД. В принципе я пользовался для symfony-проектов и bash-скриптами с rsync для файлов и ssh для остановки/старта сайта (поле в БД), миграций (можно было и без него, но не хотелось мускул наружу открывать). А аналоги есть на PHP, Phing, например, или WePloy. Capistrano просто удобнее благодаря сахару Ruby. Что не говори, а Ruby приятный язык, даже (тем более?) если не использовать «манкипатчинг» :)
А под развёртыванием я имел в виду не только, и даже не столько деплой собственно приложения, но и развертывание среды выполнения. То есть, есть свежеустановленый дистр Линукс, к которому у нас консоль или ssh/ Нужно развернуть на нём всё для деплоя рельсового приложения, да не одного, а на нескольких на виртуальных хостах. Для PHP два с половиной варианта по сути (apache + mod_php + возможно ngnix, и nginx + php-fpm), всё ставится из реп (Debian и Ubuntu имею в виду), можно из родных, можно с dotdeb и т. п. Установка — одна строка, апдейт — две строки вместе с апдейтом всей остальной ОС. В крайнем случае за PEAR надо следить, PECL на практике не встречал. C рельсами же всё сложно, особенно если хочется соблюсти debian-way и ставить всё из пакетов. Хотя пока писал коммент, обнаружил, что на dotdeb теперь и passenger есть, и ruby 1.9.3 в репах debian. Надо будет ещё раз попробовать установку провести, может без компиляции удастся установить всё.
А под развёртыванием я имел в виду не только, и даже не столько деплой собственно приложения, но и развертывание среды выполнения. То есть, есть свежеустановленый дистр Линукс, к которому у нас консоль или ssh/ Нужно развернуть на нём всё для деплоя рельсового приложения, да не одного, а на нескольких на виртуальных хостах. Для PHP два с половиной варианта по сути (apache + mod_php + возможно ngnix, и nginx + php-fpm), всё ставится из реп (Debian и Ubuntu имею в виду), можно из родных, можно с dotdeb и т. п. Установка — одна строка, апдейт — две строки вместе с апдейтом всей остальной ОС. В крайнем случае за PEAR надо следить, PECL на практике не встречал. C рельсами же всё сложно, особенно если хочется соблюсти debian-way и ставить всё из пакетов. Хотя пока писал коммент, обнаружил, что на dotdeb теперь и passenger есть, и ruby 1.9.3 в репах debian. Надо будет ещё раз попробовать установку провести, может без компиляции удастся установить всё.
Phing это ж вообще не то… А вот за WePloy спасибо, посмотрю.
Насчет, debian way, то его всё-таки стоит нарушить и поставить ruby 1.9.3 через rvm. Это наверное, единственное, что нельзя поставить из пакетов.
Насчет, debian way, то его всё-таки стоит нарушить и поставить ruby 1.9.3 через rvm. Это наверное, единственное, что нельзя поставить из пакетов.
Для PHP два с половиной варианта по сути (apache + mod_php + возможно ngnix, и nginx + php-fpm),
Как минимум, есть еще uWSGI, который с недавних пор также умеет php.
NGINX + uWSGI
Как минимум, есть еще uWSGI, который с недавних пор также умеет php.
NGINX + uWSGI
namespace, type hinting и прочие плюшки которые имеются у энтерпрайз языков, действительно облегчает использование языка в этом самом энтерпрайзе. Потому что там кроме «написали и в продакшн», есть еще долгая-долгая история в виде «поддерживаем» и «допиливаем». Да и зачастую над проектом работают не пять человек, а 25 или 50, или того больше.
С другой стороны, возможность их не использовать увеличивает разрыв между «написали и в продакшн» (как мне тут написали на днях «сайтостроителями») и «энтерпрайзом». Переход разработчика в другую «лигу» затрудняется. Сделать их обязательными — повысим порог входа и привлекательность для разработки простых сайтов и приложений.
Тоже мне проблема, которая «побуждает желание к использованию других языков»! Не нравиться? Не пиши на PHP!
Это не статья а очередной шлак очередного нытика. На ныл на целую статью, а «Решение проблемы» так и не предложил. Да и проблему то, назвать проблемой сложно.
Это не статья а очередной шлак очередного нытика. На ныл на целую статью, а «Решение проблемы» так и не предложил. Да и проблему то, назвать проблемой сложно.
думаю автокомплит поможет. мы также не помним имена всех классов.
use [ctrl+space] и выбираем себе нужный namespace
use [ctrl+space] и выбираем себе нужный namespace
Реально надуманная проблема. Пользуюсь нормальной IDE и вообще никогда не парился по поводу неймспейсов )
что-то в этом есть
Ну как бы проблема пока есть. Например, вводишь название класса Command. Он раскрывается в длиннючую малочитабельную строку \Symfony\Component\Console\Command\Command.
Альтернатива — прописовть все используемые классы в начале файла. Но это шаг назад, имхо.
Альтернатива — прописовть все используемые классы в начале файла. Но это шаг назад, имхо.
У меня IDE пишет только Command а в начало файла автоматом дописывает
use \Symfony\Component\Console\Command\Command
IDE — PhpStorm
use \Symfony\Component\Console\Command\Command
IDE — PhpStorm
Это ведь проблема не языка, а IDE.
Та нет, проблема языка, ибо всё равно дописывается вверх класса
use \Symfony\Component\Console\Command\Command.
Малозначащая и бессмысленная лишняя строка. И таких будет много.
Я к тому, что, как минимум вариант
use \Symfony\Component\Console\*
нужно было предусмотреть.
use \Symfony\Component\Console\Command\Command.
Малозначащая и бессмысленная лишняя строка. И таких будет много.
Я к тому, что, как минимум вариант
use \Symfony\Component\Console\*
нужно было предусмотреть.
use \Symfony\Component\Console;
$cmd = new Conslole\Command\Command();
use \Symfony\Component\Conslole\Command;
$cmd = new Command();
$cmd = new \Symfony\Component\Console\Command\Command();
Да, но почему вот нельзя ввести * для вгрузки классов из неймспейса, а не перечислять их каждый по очереди.
Уже третий раз коммент заново начинаю писать :) Всё не могу понять что же должно произойти при
use \Symfony\Component\Console\*.Импорт всего, что только модно из этого пакета, естественно! Что бы не наблюдать простыню из:
use some\package\name\A;
use some\package\name\B;
//…
use some\package\name\Z;
А видеть одну замечательную строчку:
use some\package\name\*;
use some\package\name\A;
use some\package\name\B;
//…
use some\package\name\Z;
А видеть одну замечательную строчку:
use some\package\name\*;
В текущей модели autoload это практически невозможно, не говоря о том, что use к импорту отношения не имеет, это скорее define. Сомневаюсь, что это вообще возможно в рамках нынешней работы autoload, в котором местонахождение источника кода класса и даже его физическая сущность никак не связаны с его полным именем. По крайней мере в лоб я вижу решение только на уровне языка связывать полное имя и физическое местонахождение. То есть не на уровне соглашений решать, что some\package\name\Z лежит в файле <include_path>/some/package/name/Z.php, а на уровне интерпретатора. Небольшой модификацией (ака костыль) может быть получится, если передавать в autoload список объявленных в данном контексте префиксов, а та будет пытаться перебирать сочетание префикс+класс до первого совпадения, но что-то такой костыль такая перспектива не радует — статический анализ ошибки не выявит.
Все реализуемо. Единственная проблема — велосипедисты, которые считают, что следование стандартов очень уж загоняет их тонкую натуру в жесткие рамки.
Понятно, что реализуемо, но, по-моему, если реализовывать хоть с намёком на обратную совместимость, то оно того не стоит. Ради того, чтобы писать
Другое дело если полностью забить на совместимость и сделать практически также как в питоне, чтобы use была именно импортом, а не «директивой препроцессора», то есть изменить семантику, а не просто синтаксис расширить. Совместить нынешнюю функциональность use и require. Или оставить use для выполнения кода для PHP версии меньше 6 :), а сделать import, которому не потребуется autoload, максимум (чтобы в рамки не загонять) потребуется какая-то функция вроде autoimport.
use some\package\name\* и использовать $a = new A; class ZZ extends Z {} вместо use some\package\name и $a = new name\A; class ZZ extends name\Z, жертвовать производительностью, да и стабильность как-то…Другое дело если полностью забить на совместимость и сделать практически также как в питоне, чтобы use была именно импортом, а не «директивой препроцессора», то есть изменить семантику, а не просто синтаксис расширить. Совместить нынешнюю функциональность use и require. Или оставить use для выполнения кода для PHP версии меньше 6 :), а сделать import, которому не потребуется autoload, максимум (чтобы в рамки не загонять) потребуется какая-то функция вроде autoimport.
use и autoload это две разные, никак не связанные вещи.
use, да и вообще весь механизм пространств имен нужен для облегчения жизни разработчику. Например, не писал по 20 раз в одном файле полное название класса\функции, а использовать для нее алиас. Или для разруливания конфликта имен, из за того что у нас есть my\super\puper\xml\Parser и my\mega\cool\json\Parser.
Все, добавление сюда звездочки говорит препроцессору (или что там у пхп с юзом работает), что у нас 100500 классов юзаются из пакета my\some\package и надо оставить это связывание для рантайма (по другому просто никак) а уже в рантайме мы дергаем другой клевый механихм, называемый автолоадом,
А автолоад — это когда интерпретатор понимает что запрашиваемого класса у него нет и поэтому он передает управление коллбекам с параметром — а ну-ка найди мне «some\package\name\A», ни один из коллбеков не вернул класс, ну что же, значит пичалька.
В той же яве все тоже самое, классы подгружаются по мере надобности, да и если что, можно за пару-тройку вечеров написать свой клевый класслоадер который будет на лету подхватывать проект, перекомпилировать измененные классы и перегружать их в рантайме.
use, да и вообще весь механизм пространств имен нужен для облегчения жизни разработчику. Например, не писал по 20 раз в одном файле полное название класса\функции, а использовать для нее алиас. Или для разруливания конфликта имен, из за того что у нас есть my\super\puper\xml\Parser и my\mega\cool\json\Parser.
Все, добавление сюда звездочки говорит препроцессору (или что там у пхп с юзом работает), что у нас 100500 классов юзаются из пакета my\some\package и надо оставить это связывание для рантайма (по другому просто никак) а уже в рантайме мы дергаем другой клевый механихм, называемый автолоадом,
А автолоад — это когда интерпретатор понимает что запрашиваемого класса у него нет и поэтому он передает управление коллбекам с параметром — а ну-ка найди мне «some\package\name\A», ни один из коллбеков не вернул класс, ну что же, значит пичалька.
В той же яве все тоже самое, классы подгружаются по мере надобности, да и если что, можно за пару-тройку вечеров написать свой клевый класслоадер который будет на лету подхватывать проект, перекомпилировать измененные классы и перегружать их в рантайме.
Так я и говорю, что use со звёздочкой потребует модернизации механизма autoload. Нельзя говорить, что они никак не связаны. Препроцессор оставит рантайму, а рантайм без модернизации не будет знать какие неймспейсы определены для данной строчки с new, extends и т. п. Модернизируя autoload (передавая ещё одним параметром список «открытых» неймспейсов), мы обрекаем его на перебор с возможностью как не получить совпадения, так и получить два и более совпадения. Первое ладно, а вот со вторым что делать? Да и вообще перебор не есть гуд, имхо.
Вот вариант типа use \Symfony\Component\Console\Command\[Command,HelpCommand,ListCommand] никаких изменений в autoload не потребует, просто сахар. А в том же python import * тоже не рекомендуется видимо по схожим причинам.
Вот вариант типа use \Symfony\Component\Console\Command\[Command,HelpCommand,ListCommand] никаких изменений в autoload не потребует, просто сахар. А в том же python import * тоже не рекомендуется видимо по схожим причинам.
Прочитайте, пожалуйста, еще раз мой комментарий, и еще раз, как работает автолоадинг на сайте php.net. Ничего там менять не придется.
Подставьте в ваш пример вместо списка классов звездочку и будет все тоже самое.
Подставьте в ваш пример вместо списка классов звездочку и будет все тоже самое.
Пойду почитаю, а вы подумайте, что должно передаться в autload при выполнении следующего кода:
На этапе «компиляции» у PHP нет никаких сведений о том, что может находиться в неймспейсах. Что он должен передать текущей реализации autoload, если класса или алиаса SomeClass он ещё не знает?
/ns1/sub1/SomeClass? /ns2/sub2/SomeClass?
Или 4 раза дёрнуть autoload с /ns1/sub1/SomeClass, /ns1/sub2/SomeClass, /ns2/sub1/SomeClass, /ns2/sub2/SomeClass. А если где-то конфликт выскочит то с ошибкой вылететь?
use /ns1/sub1/*;
use /ns1/sub2/*;
use /ns2/sub1/*;
use /ns2/sub2/*;
$obj = new SomeClass();
На этапе «компиляции» у PHP нет никаких сведений о том, что может находиться в неймспейсах. Что он должен передать текущей реализации autoload, если класса или алиаса SomeClass он ещё не знает?
/ns1/sub1/SomeClass? /ns2/sub2/SomeClass?
Или 4 раза дёрнуть autoload с /ns1/sub1/SomeClass, /ns1/sub2/SomeClass, /ns2/sub1/SomeClass, /ns2/sub2/SomeClass. А если где-то конфликт выскочит то с ошибкой вылететь?
Ну вот, сам ответил на свой вопрос :)
Так перебор же. Считаешь нормально это?
Ну автолоад сам занимается например перебором всех доступных колбек функций. В одном проекте может быть много автолоадеров, каждый от своей библиотеки. И для поиска одного класса дергаются они все.
Если два похожих автолоадера дергаются для поиска одного класса, то в чем это отличается от предложенного варианта? Дергать один автолоадер, но с другими параметрами.
Если два похожих автолоадера дергаются для поиска одного класса, то в чем это отличается от предложенного варианта? Дергать один автолоадер, но с другими параметрами.
Нужно просто избегать такой код, а не выяснять что пойдет не так.
Ну да, use к autoload не имеет отношения. Так это отлично.
Если в коде находится неизвестный класс, PHP пытается найти его в рамках используемых неймспейсов. Он последовательно перебирает все неймспейсы со звездочкой, подставляя вместо звездочки искомый класс.
Если в коде находится неизвестный класс, PHP пытается найти его в рамках используемых неймспейсов. Он последовательно перебирает все неймспейсы со звездочкой, подставляя вместо звездочки искомый класс.
Никто ведь не заставляет писать
use Application\HelloBundle\Tools\Controller; class HelloController extends Controller { //... } Можно обходиться и class HelloController extends \Application\HelloBundle\Tools\Controller { //... }. В данном контексте use лишь средство DRY, не?
Пространство имен отождествляемое с include, в коментах подключение всех файлов в комментариях… Ну-ну.
Товарищи, 2 симфа, приведенная здесь, сделала грандиозный шаг введя пространство имен в свои ряды. 1.4 тащила в любой экшн все подключенные плагины и еще кучу мусора, вторая, хоть она мне и нравится меньше первой, подключает только то, что нужно(быстрее естественно).
Судя по статье и комментариям люди ленятся прописывать лишнюю строчку сверху, при этом обожают копипастить одинаковый код снизу, или же никогда не работали с проектами огромных объемов.
Товарищи, 2 симфа, приведенная здесь, сделала грандиозный шаг введя пространство имен в свои ряды. 1.4 тащила в любой экшн все подключенные плагины и еще кучу мусора, вторая, хоть она мне и нравится меньше первой, подключает только то, что нужно(быстрее естественно).
Судя по статье и комментариям люди ленятся прописывать лишнюю строчку сверху, при этом обожают копипастить одинаковый код снизу, или же никогда не работали с проектами огромных объемов.
А где про копипастить? :)
А чем именно вам не нравится симфа2? Мне тоже по-началу не нравилась, возможно тем что «слишком много нового», но теперь привык и уже как то ломает возвращаться к первой на некоторых проектах.
Вот только прямой связи между способом подключением плагинов и неймспейсами никакой нет.
> Это ведь очень похоже на старый добрый require/require_once, не так ли?
Оператор use не вызывает автолоадер, только создаёт алиас в памяти на будущее.
> К сожалению в PHP use создает алиас во время компиляции, поэтому такой ход не сработает.
class_alias() решает эту проблему. Но зачем?
Использую use по следующим причинам:
1. Сразу видно от чего зависит данный класс
2. Во время разработки можно переключить на «подобный» класс изменив всего лишь use
Оператор use не вызывает автолоадер, только создаёт алиас в памяти на будущее.
> К сожалению в PHP use создает алиас во время компиляции, поэтому такой ход не сработает.
class_alias() решает эту проблему. Но зачем?
Использую use по следующим причинам:
1. Сразу видно от чего зависит данный класс
2. Во время разработки можно переключить на «подобный» класс изменив всего лишь use
Можно вместо use везде использовать полные имена, в таком случае класс подгрузится автоматически.
Конечно это выглядит не так красиво, но если вы используете импорт только 1 раз, то нет смысла выносить это в заголовок (некоторые скажут, что так зависимости более очевидны для разработчика).
А в целом Silex так организован тк. базируется на Symfony, где подобные загрузчики необходимы из-за проблем в поддержке большого кода.
// Hello world with Silex
require_once 'silex.phar';
$framework = new Silex\Framework(array(
'GET /hello/:name' => function($name) {
$loader = new Symfony\Component\Templating\Loader\FilesystemLoader('views/%name%.php');
$view = new Symfony\Component\Templating\Engine($loader);
return new Symfony\Component\HttpFoundation\Response($view->render(
'hello',
array('name' => $name)
));
}
));
$framework->handle()->send();Конечно это выглядит не так красиво, но если вы используете импорт только 1 раз, то нет смысла выносить это в заголовок (некоторые скажут, что так зависимости более очевидны для разработчика).
А в целом Silex так организован тк. базируется на Symfony, где подобные загрузчики необходимы из-за проблем в поддержке большого кода.
некоторые скажут, что так зависимости более очевидны для разработчикаНекоторые даже скажут, что это конвенция.
Мне кажется, что с неймспейсами в IDE будет реализовать поиск зависимостей.
Для поиска, вернее управления зависимостями и пакетами есть другие инструменты: классический PEAR, модный composer (рекомендую).
Есть еще Phark
> Использование use в предыдущем примере вам ничего не напоминает
Ога. Напоминает. Инклуды в C/C++, Import в Java… продолжать?
Ога. Напоминает. Инклуды в C/C++, Import в Java… продолжать?
Атор пишет эпический бред. Кладем всю библиотеку в один неймспейс, пишем, к примеру:
use \AdvancedORM;
Получая и автозагрузку, и разделение пространств имен, и избавивляясь от педантичности Явы. Если у кого-то настолько мало мозгов, что он каждый класс кладет в свой неймспейс, то это уже его проблемы.
use \AdvancedORM;
Получая и автозагрузку, и разделение пространств имен, и избавивляясь от педантичности Явы. Если у кого-то настолько мало мозгов, что он каждый класс кладет в свой неймспейс, то это уже его проблемы.
Извините, автора я уважаю, ибо он в отличии от многих РНР разработчиков не пытается копировать яву или руби, а занимается развитием самобытного ORM Propel. По многим вещам пропел уже удобнее даже Rails ActiveRecord, не говоря уже о Доктрине.
А теперь про эпический бред.
Вот это как раз эпический бред. Можно с таким же успехом написать: неймспейсы в PHP опциональны, не нравится — не используйте. Но никто не говорит, что они не нужны. Просто их нынешняя реализация это шаг назад в удобстве и шаг вперед в улучшении качества кода. Опять таки, оператор * из той же Java был бы совершенно не лишний и в РНР.
А теперь про эпический бред.
Кладем всю библиотеку в один неймспейс
Вот это как раз эпический бред. Можно с таким же успехом написать: неймспейсы в PHP опциональны, не нравится — не используйте. Но никто не говорит, что они не нужны. Просто их нынешняя реализация это шаг назад в удобстве и шаг вперед в улучшении качества кода. Опять таки, оператор * из той же Java был бы совершенно не лишний и в РНР.
Эпический бред пишите вы. У меня сейчас (я сейчас пишу на яве) в проекте более 200 различных пакетов, скажем так, первого уровня, com.company.product. и в которых может доходить до десятка подпакетов, в пакетах в основном не больше 3-8 классов. Знаете, когда у меня возникают трудности? Никогда, т.е. когда я в текстовом редакторе поправлю название какого-нибудь класса, а потом забуду о том, что надо еще залезть в первые строчки файла и там поправить название пакета.
Пакеты и автоматическая работа с ними — это хорошо и прекрасно. Я могу хорошо все разложить и в 3-5 кликов быстро найти нужный мне компонент, если поиск по названию класса мне не помогает.
Пакеты и автоматическая работа с ними — это хорошо и прекрасно. Я могу хорошо все разложить и в 3-5 кликов быстро найти нужный мне компонент, если поиск по названию класса мне не помогает.
А FatalError не вызовет, если писать после этого
$table = new Table(); вместо $table = new \AdvancedORM\Table();? Или это чтобы писать $table = new AdvancedORM\Table();, то есть экономить один бэкслэш?
Автор молодчина. Ведь в который раз велосипед изобретается?!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Автозагрузка в PHP: начали за здравие, а кончили за упокой