Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 82
Спасибо вам за прекрасный фреймворк! Надо уже не лениться и сделать что нибудь для души на Yii2.
Он прекрасен, спору нет. Но, во имя всей тьмы… Дух первой версии — стремление к ПРОСТОТЕ…
Попытаюсь поправить только насчет 3-его пункта. Иногда «отраслевой стандарт» вырастает именно из велосипеда.
Я не пользуюсь Yii, но заявление "Да, ваши велосипеды быстрые, да они легковесные,… это шаг в прошлое." весьма и весьма сомнительно относительно любого фреймворка.
4. Неймспейсы с маленькой буквы это дело вкуса. В Java и Scala используются маленькие буквы для именования namespace'ов и не выглядит отвратительно.
Соглашусь с вторым пунктом. именно из-за этого в большом проекте не понятно где что находится, т.к. программист в любом случае будет пользоваться тем, что ему в любом месте доступно что угодно.
1. AR и не предназначен для использования отдельно. Ни один компонент Yii не затачивается под это.
2. По мне так многоуровневая инъекция превращает код в нечитаемый и трудноотлаживаемый слоёный пирог.
3. Они уже почти полностью покрыты тестами.
4. На вкус и цвет. У меня привычка с Java, там они все в нижнем регистре и всё нормально.
2. По мне так многоуровневая инъекция превращает код в нечитаемый и трудноотлаживаемый слоёный пирог.
3. Они уже почти полностью покрыты тестами.
4. На вкус и цвет. У меня привычка с Java, там они все в нижнем регистре и всё нормально.
1) Для того, чтоб что-то использовать отдельно – не нужно затачивания под это. Нужна низкая связанность, которая является одним из критериев качества кода, кстати.
2) Чем же? Видеть где и что может поломаться при изменении заходя только в конфиг – лишь одна из многих плюшек DI.
Интересное наблюдение. Yii я бы назвал самым фрилансерским фреймворком. На нем очень просто написать, что-то работающее. Но в большинстве случаев, поддерживать проект на Yii – боль и страдание. Ибо фреймворк не пытается направлять программиста в нужное русло, и когда дело касается стандартных компонентов – связывает по рукам и ногам. Проблема с перекрытием внутренних классов фреймворка – это только вершина айсберга. Приходя в проект, ты вообще не знаешь его строения. Ctrl+F становится единственным способом отследить где и что используется.
Почему-то Symfony 2 или Zend 2, обычно намного проще поддерживать, даже если код писал не ты.
2) Чем же? Видеть где и что может поломаться при изменении заходя только в конфиг – лишь одна из многих плюшек DI.
Интересное наблюдение. Yii я бы назвал самым фрилансерским фреймворком. На нем очень просто написать, что-то работающее. Но в большинстве случаев, поддерживать проект на Yii – боль и страдание. Ибо фреймворк не пытается направлять программиста в нужное русло, и когда дело касается стандартных компонентов – связывает по рукам и ногам. Проблема с перекрытием внутренних классов фреймворка – это только вершина айсберга. Приходя в проект, ты вообще не знаешь его строения. Ctrl+F становится единственным способом отследить где и что используется.
Почему-то Symfony 2 или Zend 2, обычно намного проще поддерживать, даже если код писал не ты.
1) Низкая связанность хоть и хорошая штука в общем, но сильно портит API во многих случаях. В Yii она просто не нужна. Оттестировать мы можем любой код.
2) При использовании DI и контейнера в особенности возникают как минимум вот эти побочки:
— Сильно повышается порог вхождения, хоть принцип сам по себе и простой.
— Сложнее отлаживать. Код размазывается по конфигам, куче компонент, вырастает количество слоёв вертикально.
Ну и получаем мы с этого не так много: тестировать слабо связанный код немного проще, но не так чтобы уж слишком. Ну и если программист захочет использовать объект, он его либо вытащит из репозитория, либо инъектнет, либо протащит через конфиг контейнера. Кроме самодисциплины и ревью тут ничем не помочь.
Поэтому мы пользуемся DI умеренно и чаще без контейнера.
Что касается стандартных компонентов, особых проблем с их перекрытием быть не должно. Использовать что-то совсем иное немного проблемно, да. Но на это есть причина. Внешние пакеты. Мы стараемся избежать ситуации, когда пакет блог может использовать swift mailer, пакет feedback, zend mailer, какой-то ещё пакет, какой-то ещё мейлер. В проект вытянется очень много разных мейлеров и все их придётся поддерживать, слать в них одни и те же баги и т.д.
Про отслеживание где и что используется как-то у вас странно. Поставьте нормальную IDE. Про поддержку не согласен. Зависит больше от кода проекта, чем от фреймворка.
2) При использовании DI и контейнера в особенности возникают как минимум вот эти побочки:
— Сильно повышается порог вхождения, хоть принцип сам по себе и простой.
— Сложнее отлаживать. Код размазывается по конфигам, куче компонент, вырастает количество слоёв вертикально.
Ну и получаем мы с этого не так много: тестировать слабо связанный код немного проще, но не так чтобы уж слишком. Ну и если программист захочет использовать объект, он его либо вытащит из репозитория, либо инъектнет, либо протащит через конфиг контейнера. Кроме самодисциплины и ревью тут ничем не помочь.
Поэтому мы пользуемся DI умеренно и чаще без контейнера.
Что касается стандартных компонентов, особых проблем с их перекрытием быть не должно. Использовать что-то совсем иное немного проблемно, да. Но на это есть причина. Внешние пакеты. Мы стараемся избежать ситуации, когда пакет блог может использовать swift mailer, пакет feedback, zend mailer, какой-то ещё пакет, какой-то ещё мейлер. В проект вытянется очень много разных мейлеров и все их придётся поддерживать, слать в них одни и те же баги и т.д.
Про отслеживание где и что используется как-то у вас странно. Поставьте нормальную IDE. Про поддержку не согласен. Зависит больше от кода проекта, чем от фреймворка.
1) Низкая связанность хоть и хорошая штука в общем, но сильно портит API во многих случаях. В Yii она просто не нужна. Оттестировать мы можем любой код.
Только функциоанльные тесты на первой версии так и не завели, помнится. Насчет портит API – достаточно спорно. Оно становится несколько сложнее, возможно.
— Сильно повышается порог вхождения, хоть принцип сам по себе и простой.
Вот все эти истории про порог вхождения, и подтверждают мои слова о фрилансерском фреймворке. Поощряется подход «тяп-ляп и в продакшн». Нет необходимости глубокого изучения темы.
— Сложнее отлаживать. Код размазывается по конфигам, куче компонент, вырастает количество слоёв вертикально.
Как правило при высоком покрытии кода тестами отладка логики становится почти не нужна. Ну и насчет отладки – breakpoint'у всё равно в каком он слое, он брякнется когда выполнение дойдет до него.
Поэтому мы пользуемся DI умеренно и чаще без контейнера.
Ну в итоге это и становится единственным возможным сценарием, причем из-за фреймворковского менеджера компонентов, даже он затруднен.
Что касается стандартных компонентов, особых проблем с их перекрытием быть не должно.
Как я уже говорил, главная проблема – высокая связанность, остальные вытекающие.
Мы стараемся избежать ситуации, когда пакет блог может использовать swift mailer, пакет feedback, zend mailer, какой-то ещё пакет, какой-то ещё мейлер
При использовании модулей этот сценарий не исключается, кстати.
Про отслеживание где и что используется как-то у вас странно. Поставьте нормальную IDE. Про поддержку не согласен. Зависит больше от кода проекта, чем от фреймворка.
А как в Yii отследить что и где используется? У меня больше 20 моделей, связанных друг с другом, 4 приложения и куча компонентов и Behavior'ов. Как узнать, где используется модель User когда происходит ломающее BC изменение в ней? Только Ctrl+F(или интуиция) ибо нет централизованного DI контейнера где можно посмотреть куда была проброшена модель.
Что значит не завели функциональные тесты? Отлично работают.
По поводу брейкпоинтов, да, остановится на нём так и так. Вот только найти куда его поставить становится довольно сложно и проследить, куда далее пойдёт по коду в случае сильного использования DI-контейнера тоже непросто, даже в типизированных языках вроде Java.
Где используется отлично видно, если сделать Find Usages в том же PhpStorm.
По поводу брейкпоинтов, да, остановится на нём так и так. Вот только найти куда его поставить становится довольно сложно и проследить, куда далее пойдёт по коду в случае сильного использования DI-контейнера тоже непросто, даже в типизированных языках вроде Java.
Где используется отлично видно, если сделать Find Usages в том же PhpStorm.
Где используется отлично видно, если сделать Find Usages в том же PhpStorm.
Так и я о том же. А при использовании DI достаточно зайти в конфиг.
куда далее пойдёт по коду в случае сильного использования DI-контейнера
По моему достаточно знать lifecycle фреймворка, или библиотеки которую используешь. Да и в Yii, из-за хитрых геттеров, бихейвиоров и ивентов, ничуть не проще угадать куда пойдет выполнение, мне кажется.
Что значит не завели функциональные тесты? Отлично работают.
Забыл уточнить, я использую Codeception и у меня не получилось.
Не только у меня кажется
В конфиге так и так делать find :) К тому же, не всегда контейнер описывается в одном конфиге. Могут быть аннотации и куча конфигов.
CodeCeption в 1.1 официально не поддерживается. В 2.0 точно работать будет.
CodeCeption в 1.1 официально не поддерживается. В 2.0 точно работать будет.
Конфиги – централизованый узел системы. Если искать только там – это не проблема. Без DI искать надо и в конфиге и в компонентах и в расширениях и вообще везде по проекту(особенно если это статический хелпер, например).
Лучше 10 файлов конфига, чем 200 файлов .php. Аннотации для DI – конечно хуже, но, как правило, они контекстны хотя-бы.
Лучше 10 файлов конфига, чем 200 файлов .php. Аннотации для DI – конечно хуже, но, как правило, они контекстны хотя-бы.
Забыл уточнить, я использую Codeception и у меня не получилось.
Признаюсь: да, на данный момент есть проблемы с интеграцией. Но хорошая новость: она возможна.
Я знаю несколько проектов где функциональные тесты работают, но пока на костылях. То есть скорее всего, нет элегантного и универсального решения которое можно было б использовать из коробки. Но с небольшой долей энтузиазма и напильника тестировать проект на Yii1 можно. Вы сможете помочь, если разберетесь с нашыми «костылями» и поможете в их разработке ) Проблема ещё в том, что пока нет активных меинтейнеров этого самого YiiBridge и Yii1 модуля.
Хотелось бы дать более удоволетворительный ответ, но пока такие дела. Если нет времени играться — используйте PhpBrowser, он универсален.
Чуть дополню:
1. Хелперы не наследуются от Object. В массиве свойства объектов по умолчанию.
1. Хелперы не наследуются от Object. В массиве свойства объектов по умолчанию.
Уже (последние 3 дня) пишу тестовый проект. Пока очень непривычно, но мне нравится :) Мыши плакали, кололись...
Летом писали тестовый проект корпоративной соц. сети с плюшками. Писали на Yii2, контрибутили по чуть-чуть и создавали issue…
Очень понравился ActiveRecord и вообще, многое продумано. После CI, Kohana перехожу на Yii2 и жду стабильный релиз.
Очень понравился ActiveRecord и вообще, многое продумано. После CI, Kohana перехожу на Yii2 и жду стабильный релиз.
Думаю, что это будет не слишком тактично, но рискну посоветовать взглянуть на Laravel 4
Да чего уж на laravel. Давайте уж сразу про рельсы писать)) Ну топик же про Yii2
Топик про yii, а комментарий про радость перехода с различных фреймов на yii. Не думаю, что мой комментарий не уместен, но т.к. верно указано — топик про yii — я и заметил, что это не слишком тактично с моей стороны об этом писать.
Заодно про рельсы:
Заодно про рельсы:
небольшой шарж =)
объясните, пожалуйста, суть для тех, кто не совсем в теме про laravel/rails
Рельсы у рубистов считаются верхом совершенства. Ларавельку же, php комьюнити считает «убийцей» рельс.
Лично по моему мнению — да, схожесть местами есть, в некоторых местах даже удобнее (учитывая то, что я лишь процентов на 30% знаю одно и другое, так что не вполне компетентен), правда проблемы с синтаксисом, но это уже проблемы PHP, т.к. много вещей выглядят иначе, просто из-за того, что это другой язык.
upd: хелперы один в один, AR очень похожа, только связи между моделями проще в ларавельке. Конфиги у рельс через yml и простые, у лары стандартным пыхом и в разы объёмнее, что компенсируется тем, что приложение со всеми конфигами создаёт установщик (композер) ну и прочее… Могу много ещё чего написать =) но это оффтоп
Лично по моему мнению — да, схожесть местами есть, в некоторых местах даже удобнее (учитывая то, что я лишь процентов на 30% знаю одно и другое, так что не вполне компетентен), правда проблемы с синтаксисом, но это уже проблемы PHP, т.к. много вещей выглядят иначе, просто из-за того, что это другой язык.
да, схожесть местами есть
upd: хелперы один в один, AR очень похожа, только связи между моделями проще в ларавельке. Конфиги у рельс через yml и простые, у лары стандартным пыхом и в разы объёмнее, что компенсируется тем, что приложение со всеми конфигами создаёт установщик (композер) ну и прочее… Могу много ещё чего написать =) но это оффтоп
Быть может так считает только laravel-сообщество? Я хоть и не люблю RoR, но как по мне она все же на несколько уровней выше стоит.
Не зная предмет обсуждения — нельзя сравнивать. А те кто писали на чём-то, вполне могут отнести себя к этому сообществу. Из чего можно сделать вывод, что только laravel-сообщество так считает =)
В любом случае я слышал о данном высказывании (и даже нашёл подобный дем в интернете), о чём и поведал, ответив на вопрос.
В любом случае я слышал о данном высказывании (и даже нашёл подобный дем в интернете), о чём и поведал, ответив на вопрос.
Конфиги у рельс через yml
Что-то мне подсказывает, что рельсы вы не знаете
А потому я не уверен, что вы всерьез можете утверждать что ларавелька — убийца рельс. До рельс ларе плясать и плясать, а экосистема рельс опережает ларавелку на много лет вперед.
Киской ошиблись)
Уже написали несколько проектов на Yii2, один из них даже в продакшене. Переход на вторую версию сначала был очень тяжелый. Но потом, после того как серъезно перекопали весь код, и главное перестроились у себя в голове на новую концепцию, все пошло очень даже. Теперь только Yii2, отличный фреймворк! Когда допилят вообще цены не будет.
Мы уже третий месяц пишем большой проект на Yii2. Впечатления только положительные. Теперь скорее Yii1 вызывает недоумение и заставляет вспоминать как же оно там делалось и как же оно неудобно по сравнению с 2. Молодцы, главное темпа не терять.
Отличная новость! Спасибо за ваш труд!
Молодцы что решили перейти на PHP 5.4, компактные массивы здорово улучшают читабельность кода.
Молодцы что решили перейти на PHP 5.4, компактные массивы здорово улучшают читабельность кода.
Ну вам никто не мешал и 1,1,* использовать вместе с php5.4. У меня уже на 5,5 крутится.
Я имел в виду массивы в коде фреймворка и расширений.
а между тем что мы видим в коде фреймворка. Да, конечно же использование сокращенной натации массивов это круто, но… Каким именно образом функции basename и dirname попали в StringHelper? Разве это относится именно к строкам или все же нужно было реализовать PathHelper? И я не сильно улавливаю, зачем делать пустой класс StringHelper унаследованный от BaseStringHelper?
Если еще пройтись по коду:
а как же is_callable? И вообще, почему для работы со строками используются обертки (только для функций strlen и substr) а для работы с датой и временем DateTime объект все еще не поддерживается? (да, тут оно и ненужно, согласен, но в моделях использовать для хранения данных DateTime довольно удобно).
Если еще пройтись по коду:
/**
* Gets the current timestamp.
* @return mixed the timestamp value
*/
protected function evaluateTimestamp()
{
if ($this->timestamp instanceof Expression) {
return $this->timestamp;
} elseif ($this->timestamp !== null) {
return call_user_func($this->timestamp);
} else {
return time();
}
}
а как же is_callable? И вообще, почему для работы со строками используются обертки (только для функций strlen и substr) а для работы с датой и временем DateTime объект все еще не поддерживается? (да, тут оно и ненужно, согласен, но в моделях использовать для хранения данных DateTime довольно удобно).
Пустой класс нужен для возможности статического «наследования» через LSB путём подмены пустого через classmap.
Порефакторил: github.com/yiisoft/yii2/pull/1416
github.com/yiisoft/yii2/issues/1368 — хотите сильно связанные компоненты — используйте yii…
Автор yii все правильно ему сказал. Иногда стоит подумать, все ли ты правильно делаешь, когда у тебя появляются подобные безумные идеи. Возможно, ты просто не понимаешь философию разработчиков фреймворка.
+автор явно указал на возможность доступа к thead без расширения базовых классов
Правильно? Где? Первый его ответ? А дальнейшая дискуссия вас не повергает в уныние? Добавление класса через кастыль из jQuery, попытка убедить разработчика что ему ненужна возможность кастомизации представления, если есть возможность просто задать нужный селектор. При чем при этом видимо не задумываются о том что это может усложнить реализацию каких-то вещей на js да и просто изуродует css.
Зачем Yii 2, когда есть Laravel 4?
По-моему, выбор — это замечательно.
опишите коротко разницу. первый раз слышу про Laravel
лара появился около 2х лет назад (2011 год) — на данный момент второй по количеству звёзд и форков на гитхабе php фреймворк после Symfony, но, предполагаю, через месяц будет самым популярным. github.com/search?l=PHP&o=desc&q=php+framework&ref=searchresults&s=stars&type=Repositories В 3 раза больше пакетов на packagist, нежели у yii и самый динамично-развивающийся фрейм на PHP на данный момент — это если говорить о понтах.
Основан на Symfony 2 и некоторых пакетах Composer. Очень простой для старта и предоставляет возможности для серьёзных проектов. Местами, «из коробки» возможностей не хватает (например модели слишком сильно завязаны на БД, и статические обёртки для доступа к компонентам могут пугать), можно даже считать, что не подходит для чего-то серьёзного, но напильником очень просто кастомизируется.
От себя лично: Перешёл с Zend на Yii, затем на Laravel. Считаю его наиболее приемлемым из разряда малый\средний проект и наверное с самыми образцовыми исходниками что я видел, после\на равне Symfony 2.
Думаю наиболее краткое описание
Основан на Symfony 2 и некоторых пакетах Composer. Очень простой для старта и предоставляет возможности для серьёзных проектов. Местами, «из коробки» возможностей не хватает (например модели слишком сильно завязаны на БД, и статические обёртки для доступа к компонентам могут пугать), можно даже считать, что не подходит для чего-то серьёзного, но напильником очень просто кастомизируется.
От себя лично: Перешёл с Zend на Yii, затем на Laravel. Считаю его наиболее приемлемым из разряда малый\средний проект и наверное с самыми образцовыми исходниками что я видел, после\на равне Symfony 2.
Думаю наиболее краткое описание
У Yii практически нет пакетов на packagist потому как Composer поддерживается со второй версии, которой до релиза далеко.
Я не говорю, что лара чем-то лучше или хуже юи (или йии). Просто она изначально писалась с расчётом на современный PHP, с оглядкой на другие фреймы, не обязательно на PHP (многое почёрпнуто из рельс). Попросили описать, что же это за зверь такой — постарался наиболее кратко описать достоинства и недостатки с небольшим введением, в виде того, что на данный момент — это один из популярнейших фреймов (намёк на то, что странно, что не слышали о нём).
ну недостатки вы так и не описали
Излишняя завязка на БД моделей. Статические обёртки (провайдеры) неявные. Исходный пакет (т.е. стартовое приложение, которое появляется сразу после инсталла) заточен только под одно приложение. Таскает за собой слишком дофига всего на все случаи жизни (там даже доктрина в пакеты включена). AR местами избыточно зависит от сторонних пакетов, например от Carbon (работа с датой\временем). Написан без PSR-2, хотя соблюдает PSR-0 и 1, в том числе генераторы (artisan controller:make, migrate:make, etc...) создают исходники, которые потом править приходится. Роутинг по умолчанию излишне гибкий и основан на PHP — это и не минус и не плюс, просто иногда он очень большим может быть, нежели используя какой-нибудь DSL, вроде yml.
Ну это если с первого взгляда.
Ну это если с первого взгляда.
Основная разница в том, что изначально фреймворк ориентируется на более новые версии PHP (5.3 в минимуме), а поэтому — код чище и нагляднее за счет «магии» (везде Fluent). Также, фреймворк ориентирован на TDD и REST. Идеально для написания api. Сразу же использует composer, что сильно облегчает обновление и публикацию сайтов. Yii хорош, но старенький он уже.
Поэтому и появился 2.0.
Помню когда Кванг анонсировал изменения в ar для yii (года так 2 назад если мне память не изменяет), и уже тогда я немного расстроился. Описанные им изменения хоть и являлись довольно глобальными и нужными, но создавалось впечатление что проект начал развиваться медленнее. Что уж говорить о том, что в течении этих 2-х лет получить внятную информацию о состоянии дел почти не удавалось. Обычно все вопросы ограничивались «когда закончим тогда и закончим». При таком раскладе использовать фреймворк для коммерческой разработки просто не выгодно. У проекта попросту не было внятного roadmap. В то же время за эти 2-3 года появилась масса инструментов вроде composer, у php появились стандарты (хоть какие-то), появилась масса интересных фреймворков и библиотек. Словом даже как-то грустно… Хотя своя аудитория у yii будет всегда как мне кажется.
А зачем Laravel 4 когда есть <впишите свой любимый фреймворк>. На вкус и цвет как говорится. Меня лично Laravel со всякими его «фасадами» не впечатлил. Зачем разводить холивар?
Зачем Laravel 4, когда есть Ruby on Rails 4?
см. в спойлере: habrahabr.ru/post/204578/#comment_7055182 =)
Спасибо за работу. После пары дней с Yii2, Yii1 уже даже как-то непривычен, видимо к хорошему привыкаешь быстро.
Молодцы ребята. Но вот у меня возник такой вопрос,
class Controller extends \yii\base\Controller
, почему не используете use, так как есть рекомендация по неймспейсам выносить вверх только в случае, если более одного раза включаются объекты его (по-моему это из си)?
class Controller extends \yii\base\Controller
, почему не используете use, так как есть рекомендация по неймспейсам выносить вверх только в случае, если более одного раза включаются объекты его (по-моему это из си)?
Алиас не хотелось задавать.
просто как-то странно для yii\helpers\Html и для yii\base\InlineAction есть, а для контроллера нет
Тут у нас получается два одноимённых класса. PHP не позволяет использовать их без задания алиаса аля
use \yii\base\Controller as BaseController;. Чтобы народ не путать названием BaseController, сделано без алиаса.мне кажется что этим вы только и будете вводить людей в заблуждение. У вас среди компонентов масса классов, даже находящихся в одном и том же нэймспейсе, которые спокойно наследуются от какого-то Base класса. Почему бы не делать все одинаково?
А вы не запутаете народ никак, так как в приложении будет
namespace app\common;
use yii\base\Controller as BaseController;
class Controller extends BaseController {}
Ну, тогда мб стоит переделать чутка. Я особой разницы не вижу, но если режет глаз, почему нет? В github если закинуть, наверняка поправим.
Я тоже за чтоб был порядок.
1. Все классы импортировать через use, даже из корневого пространства (классы PHP и тд).
2. Не импортировать классы используемые только в phpDoc
1. Все классы импортировать через use, даже из корневого пространства (классы PHP и тд).
2. Не импортировать классы используемые только в phpDoc
А из корня-то зачем импортировать?
Чтобы нигде в коде не было классов типа \Foo, ниже два примера
namespace foo;
use DateTime;
class Bar
{
function __construct()
{
return new DateTime();
}
}
namespace foo;
class Bar
{
function __construct()
{
return new \DateTime();
}
}
мне кажется в корне должен находится только 1 класс приложения
А стандартные классы PHP где должны быть?
Это перегиб. Классы стандартные аля \DateTime или там \ArrayAccess или что либо еще не нужно импортировать. Они и так доступны в любом простанстве имен. Так же не вижу смысла импортировать классы при подключении (скажем расширений) и инициализации оных в больших количествах. Как пример — расширения для twig или еще чего. Мне кажется это логичным. Засорять код лишними юзами тоже не хорошо.
Они не доступны в любом пространстве, они доступны из своего корневого пространства, зачем их каждый раз оттуда тянуть?
Мне не кажется что это лишний use.
Мне наоборот удобнее заглянуть в заголовок файла и узнать какие классы используются. И в случае чего заменить что-то.
Хотя это опять же дело вкуса, современные ИДЕ делают многие вещи за программиста.
Мне не кажется что это лишний use.
Мне наоборот удобнее заглянуть в заголовок файла и узнать какие классы используются. И в случае чего заменить что-то.
Хотя это опять же дело вкуса, современные ИДЕ делают многие вещи за программиста.
Я в таких случаях делаю так:
use yii\base;
class Controller extends base\Controller
use yii\base;
class Controller extends base\Controller
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Yii 2 alpha