Pull to refresh

Comments 116

Качество большинства библиотек всегда было не на высоком уровне. Может хоть теперь что-то изменится.
Стоит наверное отметить, что хотя use и находится в том же месте, где раньше был require, он несёт совершенно иной смысл, а именно указывает, какой конкретно класс мы хотим использовать в качестве контроллера в данном неймспейсе.
Привнесенная неймспейсами многословность


Разве?

Zend_Cache_Backend_Memcached vs \Zend\Cache\Backend\Memcached
Второй вариант длиннее на символ)
хотя ИМХО, если бы смотрели в стороне гемов, обозвали бы \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);
А причём тут есть или нет? Они следуют их соглашению.
Какая разница чему конктрено следуют, если результат один — "_" в именах классов преобразуется в DIRECTORY_SEPARATOR пути к файлу и наоборот.
а кому-то может удобно знать к какому модулю относиться класс

это дело вкуса
Согласен, но все равно не удобно. Имея grep я за «пару секунд» узнаю к какому модулю относится класс.
А если, не дай бог, на винде придётся правки вносить? cygwin ставить? :)

На самом деле не для удобства автолоадера это сделано, а для удобства клиентов (разработчиков) — знать где какой класс искать без grep'а и как свои именовать и куда их складывать, чтобы другие с первого взгляда (а не с «парой секунд» и grep'ом) могли понять, что где находится. Автолоадеру проще было бы работать с хэшем 'имя класса' -> 'путь'. Но вот нужно вам в своё приложение включить только часть ZF (как это обычно и бывает, связанность у модулей очень низкая в ZF) — полезете в автолоадер или grep запускать, чтобы узнать какие файлы вам нужно в свой проект скопировать? А если этих файлов с десяток-другой-третий? Но у всех один префикс третьего уровня? Уже «минута» только чтобы их найти, а нужно ещё и скопировать.
Никто не запрещает делать логическую структуру директорий и при этом использовать короткие имена классов.
К примеру Symfony 1.x, каждый плагин имеет свой префикс (обычно 2 символа) и свою директорию.
И найти все получается достаточно просто.
Мне это было неудобно. На ZF с тоской смотрел в этом плане.
Я бы не сказал, что дело вкуса. Дело, скорее, стандартизации, единого подхода. И разграничения ответственностей и инкапсуляции.
Зато сразу понятно, что это за класс, а автоподстановка в любой IDE позволяет набирать имена классов любой длины.
После PHP с Zend Framework-ом и Autoloader-ом трудно привыкнуть к хитросокращённым названиям классов в других фреймворках и языках :)
Обычно в начале любой книге по программированию написано, что имена переменных должны быть максимально краткими и нести максимальную смысловую нагрузку.
Почему-то никто не пишет
$product_That_Need_To_Be_Added_To_Shopping_Cart = ....;

Я конечно утрирую, но смысл тот же
Покажите мне эту книгу, пожалуйста.
Наверное, она из тех времён, когда имя файла не могло быть длиннее 8 символов, и имена баз данных и таблиц не должны были превышать 4 символа в длину :)

И как назвать класс Zend_Db_Adapter_Abstract? zf_dbadpabst?
Как минимум выбросить слово Abstract. zfDbAdapter
А как тогда назвать не абстрактный класс Zend_Db_Adapter, если вдруг такой будет? И как отличать абстрактный класс от класса с имплементацией? И что там с книгой?
У автозагрузки есть один большой плюс.
Вы можете реализовать в атозагрузчике сборку всех классов в один файл. И потом подключать его одним require. Профит
Можно поподробнее? У меня при включенном акселераторе (apc.stat=0) не заметно никакой разницы.
У меня включение одного файла со всеми используемыми классами (примерно 3 Мб) с acp.stat=0 дало ускорение в 2-2.5 раза
Интересно, прибавка приличная. Проект на Симфони2? В автозагрузчике используется is_file (ClassLoader) или isset classmap (MapClassLoader)?
Проект на симфони компонентах. У меня автозагрузка через include_path реализована. Т.е. я явно не занимаюсь поиском файла и проверки на его существование
Понятно, спасибо. У меня на карте с полными путями. Возможно, эффект наблюдается когда очень много кода. Надо будет позже протестировать.
Т.е. у меня реализована след образом. Автолоадер с начала отсеивает классы которые не нужно паковать — это в основном классы моделей Доктрин ибо там свои приколы с парсингом неймпспейсов, далее заменяет константы типа __FILE__ на соотв. пути, добавляет класс в общий файл, чистит apc кеш ибо в противном случае получим бесконечное разбухание файла классов.

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

Но поработать напильником пришлось. Особенно с путями и некоторыми и доктрин моделями
Интересное решение. А можно реализацию где-нибудь увидеть, например на гитхабе?
Java тут совершенно не причем. Просто PHP движется к enterprise миру, где затраты на написание составляют лишь мизерную часть проекта. Это и не хорошо, и не плохо. Просто нужно понимать где и когда какой фреймворк использовать и использовать ли их вообще.
Вы действительно считаете, что наличие длинных неймспейсов делает ту или иную технологию уровня enterprise?
Я где-то писал только про namespace'ы? Я смотрю в целом на развитие фреймворков и самого языка.

Имхо, двигаться в сторону enterprise — логично. Ибо это даст поддержку крупных и надежных работодателей. Что повысит потенциальные з/п, что повысит престижность языка.
Но для этого надо быть не «как джава», а быть «лучше джава».
А пока только копируются существующие в джава решения, но там они были вызваны особенностями технологии, а в PHP внедряются «потому что это энтерпрайз».

Как бы не вышло так, что PHP и сегмент простых, легких применений потеряет, и до энтерпрайза так и не доберется.
В чём-то уже лучше. Или ещё? :-/ Одним из главных преимуществ PHP всегда было, имхо, простота развертывания приложения. Тем более возможностей писать «спагетти» никто (пока?) не отнимает.
С ужасом жду тех дней, когда программы на PHP будут компилироваться :)
Если прозрачный JIT, то почему нет? А так они и сейчас компилируются в байт-код, а с акселераторами и JIT получается.
Не получается, и не получиться, пока полноценного JIT-компилятора не будет у PHP. А его не будет там никогда.
Простота развертывания? А как же 100500 параметров, задающихся через ini-файлы?
Это уже тюнинг :) Если что я имею в виду Debian-based дистрибутивы Linux и LAMP.
Не всегда это тюнинг. Создателям php долго доказывали, что задание в настройках register globals и magic quotes — зло, и они это поняли. Но почему-то до них не доходит что задание любых настроек в общем случае — зло, ведь от этих настроек зависит работоспособность кода, а значит код перестает быть самодостаточным.
Да, сам язык такой ентерпрайс… Без много поточности, без нативной поддержки utf, без возможности писать что-либо серьезное помимо веб-приложений. Python и Ruby гораздо больший ентерпрайс, но почему-то вот не пытаются копировать в себе Джаву. При этом, есть и JRuby, IronRubym JPython,… То есть эти языки поддерживаются на ентерпрайс уровне без каких-либо синтаксмических или фреймворковых нововведений.

Если вы считаете, что наличие аннотаций, dependency injection, namespaces делает язык ентерпрайсом вы крайне ошибаетесь. Это просто независимые вещи. А вот то, что PHP в гонитве за статусом и пытается стать недоджавой, это печально.
Прочтите мой коммент внимательно. Там только, по сути, про «пытается стать недоджавой» и написано. Только другими словами. Да, наверное, моя ошибка в том, что недостаточно раскрыл мысль.

ЗЫ: Лично я к PHP отношусь очень прохладно и пишу на нем только потому что *пока*что* мой основной заработок идет именно с него. Но это не тема этого обсуждения.
Ну тогда ок, почти коллеги )
Мне вот не нравится, что игнорируя все хорошие фишки РНР сообщество пытается создать некую видимость ентерпрайса. Конечно, хорошо, что библиотеки становятся стандартизироваными, чем-то похожими, но плохо, что количество фреймворков до сих пор не дает нужную легкость в разработке.
О. Не один я такой. Заказчики люди консервативные и любят php.
Кроме того заказчики ещё люди рациональные — они учитывают не только стоимость разработки, но и развёртывания, администрирования и поддержки (кода). Почему-то за развёртывание, например, rails приложения на «голом» Линуксе админ-фрилансер или саппорт (в)дс-хостинга берёт больше, чем за развёртывание приложения на PHP(+ZF/Yii/Symfony/...). Меня неоднократно на хабре пытались убедить, что приложение под рельсами развернуть чуть ли не проще чем на голом пхп. Если так, то почему дороже?
Я тоже так считаю. Причём считаю это куда большим плюсом PHP, сыгравший, вкупе с грубо говоря $_*, на его популярности больше, чем Си-подобный синтаксис и встраивание в HTML вместе взятые.
Смотря где. С появлением 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. Надо будет ещё раз попробовать установку провести, может без компиляции удастся установить всё.
Phing это ж вообще не то… А вот за WePloy спасибо, посмотрю.

Насчет, debian way, то его всё-таки стоит нарушить и поставить ruby 1.9.3 через rvm. Это наверное, единственное, что нельзя поставить из пакетов.
Для PHP два с половиной варианта по сути (apache + mod_php + возможно ngnix, и nginx + php-fpm),

Как минимум, есть еще uWSGI, который с недавних пор также умеет php.

NGINX + uWSGI
Как-то пропустил эту новость.
namespace, type hinting и прочие плюшки которые имеются у энтерпрайз языков, действительно облегчает использование языка в этом самом энтерпрайзе. Потому что там кроме «написали и в продакшн», есть еще долгая-долгая история в виде «поддерживаем» и «допиливаем». Да и зачастую над проектом работают не пять человек, а 25 или 50, или того больше.
С другой стороны, возможность их не использовать увеличивает разрыв между «написали и в продакшн» (как мне тут написали на днях «сайтостроителями») и «энтерпрайзом». Переход разработчика в другую «лигу» затрудняется. Сделать их обязательными — повысим порог входа и привлекательность для разработки простых сайтов и приложений.
Тоже мне проблема, которая «побуждает желание к использованию других языков»! Не нравиться? Не пиши на PHP!

Это не статья а очередной шлак очередного нытика. На ныл на целую статью, а «Решение проблемы» так и не предложил. Да и проблему то, назвать проблемой сложно.
ТОЛЬКО ХАРДКОР ТОЛЬКО ПЭХАПЭ
Это шутка? Сарказм? Что за идиотский комментарий?
UFO landed and left these words here
думаю автокомплит поможет. мы также не помним имена всех классов.
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.

Малозначащая и бессмысленная лишняя строка. И таких будет много.

Я к тому, что, как минимум вариант

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\*;
В текущей модели autoload это практически невозможно, не говоря о том, что use к импорту отношения не имеет, это скорее define. Сомневаюсь, что это вообще возможно в рамках нынешней работы autoload, в котором местонахождение источника кода класса и даже его физическая сущность никак не связаны с его полным именем. По крайней мере в лоб я вижу решение только на уровне языка связывать полное имя и физическое местонахождение. То есть не на уровне соглашений решать, что some\package\name\Z лежит в файле <include_path>/some/package/name/Z.php, а на уровне интерпретатора. Небольшой модификацией (ака костыль) может быть получится, если передавать в autoload список объявленных в данном контексте префиксов, а та будет пытаться перебирать сочетание префикс+класс до первого совпадения, но что-то такой костыль такая перспектива не радует — статический анализ ошибки не выявит.
Все реализуемо. Единственная проблема — велосипедисты, которые считают, что следование стандартов очень уж загоняет их тонкую натуру в жесткие рамки.
Понятно, что реализуемо, но, по-моему, если реализовывать хоть с намёком на обратную совместимость, то оно того не стоит. Ради того, чтобы писать 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 со звёздочкой потребует модернизации механизма autoload. Нельзя говорить, что они никак не связаны. Препроцессор оставит рантайму, а рантайм без модернизации не будет знать какие неймспейсы определены для данной строчки с new, extends и т. п. Модернизируя autoload (передавая ещё одним параметром список «открытых» неймспейсов), мы обрекаем его на перебор с возможностью как не получить совпадения, так и получить два и более совпадения. Первое ладно, а вот со вторым что делать? Да и вообще перебор не есть гуд, имхо.

Вот вариант типа use \Symfony\Component\Console\Command\[Command,HelpCommand,ListCommand] никаких изменений в autoload не потребует, просто сахар. А в том же python import * тоже не рекомендуется видимо по схожим причинам.
Прочитайте, пожалуйста, еще раз мой комментарий, и еще раз, как работает автолоадинг на сайте php.net. Ничего там менять не придется.

Подставьте в ваш пример вместо списка классов звездочку и будет все тоже самое.
Пойду почитаю, а вы подумайте, что должно передаться в autload при выполнении следующего кода:
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. А если где-то конфликт выскочит то с ошибкой вылететь?
Ну вот, сам ответил на свой вопрос :)
Так перебор же. Считаешь нормально это?
Ну автолоад сам занимается например перебором всех доступных колбек функций. В одном проекте может быть много автолоадеров, каждый от своей библиотеки. И для поиска одного класса дергаются они все.

Если два похожих автолоадера дергаются для поиска одного класса, то в чем это отличается от предложенного варианта? Дергать один автолоадер, но с другими параметрами.
Точно, значит если 4 автолодера и 4 use *, значит дёргаться будет 16 раз :)
Нужно просто избегать такой код, а не выяснять что пойдет не так.
Ну да, use к autoload не имеет отношения. Так это отлично.

Если в коде находится неизвестный класс, PHP пытается найти его в рамках используемых неймспейсов. Он последовательно перебирает все неймспейсы со звездочкой, подставляя вместо звездочки искомый класс.
И каждый раз вызывает autoload? Ведь только она знает где и как физически находится класс.
Никто ведь не заставляет писать use Application\HelloBundle\Tools\Controller; class HelloController extends Controller { //... } Можно обходиться и class HelloController extends \Application\HelloBundle\Tools\Controller { //... }. В данном контексте use лишь средство DRY, не?

Пространство имен отождествляемое с include, в коментах подключение всех файлов в комментариях… Ну-ну.

Товарищи, 2 симфа, приведенная здесь, сделала грандиозный шаг введя пространство имен в свои ряды. 1.4 тащила в любой экшн все подключенные плагины и еще кучу мусора, вторая, хоть она мне и нравится меньше первой, подключает только то, что нужно(быстрее естественно).

Судя по статье и комментариям люди ленятся прописывать лишнюю строчку сверху, при этом обожают копипастить одинаковый код снизу, или же никогда не работали с проектами огромных объемов.
В голове тех, кто не понимает зачем создали пространство имен. Его же не ради прикола ввели в php, а чтобы была возможность еще больше стандартизировать взаимодействие с классами и процесс разработки, тем самым уменьшив время разработки и кол-во кода.
А чем именно вам не нравится симфа2? Мне тоже по-началу не нравилась, возможно тем что «слишком много нового», но теперь привык и уже как то ломает возвращаться к первой на некоторых проектах.
Вот только прямой связи между способом подключением плагинов и неймспейсами никакой нет.
> Это ведь очень похоже на старый добрый require/require_once, не так ли?

Оператор use не вызывает автолоадер, только создаёт алиас в памяти на будущее.

> К сожалению в PHP use создает алиас во время компиляции, поэтому такой ход не сработает.

class_alias() решает эту проблему. Но зачем?

Использую use по следующим причинам:
1. Сразу видно от чего зависит данный класс
2. Во время разработки можно переключить на «подобный» класс изменив всего лишь use
Можно вместо use везде использовать полные имена, в таком случае класс подгрузится автоматически.

// 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, где подобные загрузчики необходимы из-за проблем в поддержке большого кода.
некоторые скажут, что так зависимости более очевидны для разработчика

Некоторые даже скажут, что это конвенция.
Я за подобные конструкции, просто автор ругается на них и я показал другой путь :).

P.S. Вы промазали ;).
Вечно промазываю когда на последний коммент в посте отвечаю :(
Мне кажется, что с неймспейсами в IDE будет реализовать поиск зависимостей.
Для поиска, вернее управления зависимостями и пакетами есть другие инструменты: классический PEAR, модный composer (рекомендую).
UFO landed and left these words here
> Использование use в предыдущем примере вам ничего не напоминает

Ога. Напоминает. Инклуды в C/C++, Import в Java… продолжать?
UFO landed and left these words here
Cкорее #define

use /A/B/C;
$o = new C/D();


что-то вроде

#define C /A/B/C
$o = new C/D();

Атор пишет эпический бред. Кладем всю библиотеку в один неймспейс, пишем, к примеру:

use \AdvancedORM;

Получая и автозагрузку, и разделение пространств имен, и избавивляясь от педантичности Явы. Если у кого-то настолько мало мозгов, что он каждый класс кладет в свой неймспейс, то это уже его проблемы.
Извините, автора я уважаю, ибо он в отличии от многих РНР разработчиков не пытается копировать яву или руби, а занимается развитием самобытного ORM Propel. По многим вещам пропел уже удобнее даже Rails ActiveRecord, не говоря уже о Доктрине.

А теперь про эпический бред.
Кладем всю библиотеку в один неймспейс

Вот это как раз эпический бред. Можно с таким же успехом написать: неймспейсы в PHP опциональны, не нравится — не используйте. Но никто не говорит, что они не нужны. Просто их нынешняя реализация это шаг назад в удобстве и шаг вперед в улучшении качества кода. Опять таки, оператор * из той же Java был бы совершенно не лишний и в РНР.
Эпический бред пишите вы. У меня сейчас (я сейчас пишу на яве) в проекте более 200 различных пакетов, скажем так, первого уровня, com.company.product. и в которых может доходить до десятка подпакетов, в пакетах в основном не больше 3-8 классов. Знаете, когда у меня возникают трудности? Никогда, т.е. когда я в текстовом редакторе поправлю название какого-нибудь класса, а потом забуду о том, что надо еще залезть в первые строчки файла и там поправить название пакета.

Пакеты и автоматическая работа с ними — это хорошо и прекрасно. Я могу хорошо все разложить и в 3-5 кликов быстро найти нужный мне компонент, если поиск по названию класса мне не помогает.

А FatalError не вызовет, если писать после этого $table = new Table(); вместо $table = new \AdvancedORM\Table();? Или это чтобы писать $table = new AdvancedORM\Table();, то есть экономить один бэкслэш?
Автор молодчина. Ведь в который раз велосипед изобретается?!
Sign up to leave a comment.

Articles