Состоялся релиз PHP фреймворка Yii версии 2.0.11. Инструкции по обновлению и установке можно найти на официальном сайте. Версия 2.0.11 содержит более 110 улучшений и исправлений.
Четыре небольших изменения могут затронуть существующие приложения, так что стоит обратить внимание на UPGRADE.md.
Огромное спасибо нашему замечательному сообществу. Мы сделали это вместе!
За процессом разработки Yii 2 можно следить поставив звёздочку на GitHub. Также у нас есть Twitter и Facebook.
Так как уже ведутся работы над Yii 2.1, убедитесь, что версия фреймворка в composer.json прописана как ~2.0.11. В противном случае после релиза 2.1 проект может поломаться.
Далее мы рассмотрим самые интересные изменения и улучшения, вошедшие в релиз. Полный список доступен в CHANGELOG.
Покрытие тестами
Мы решили не принимать pull request-ы без тестов за редким исключением. Это должно улучшить качество кода и уменьшить время, затрачиваемое на его проверку. Более половины pull request-ов для 2.0.11 были приняты согласно этому решению.
Некоторые тесты, такие как тесты для менеджера URL, подверглись значительному рефакторингу. Методы стали меньше, читать их стало проще.
Алексей Рогачёв проделал значительную работу по рефакторингу, исправлению и покрытию тестами JavaScript-части фреймворка.
Консоль
В консоли Bash и Zsh стало довольно просто организовать дополнение для команды ./yii. Настройка описана в руководстве.
Кроме того, при описках консоль подсказывает существующие команды с похожим написанием.
Кеш
Стало возможным выставить глобально длительность хранения данных в кеше через yii\caching\Cache::$defaultDuration.
Появился удобный синтаксис:
$data = $cache->getOrSet($key, function () {
return $this->calculateSomething();
});Код выше делает то же, что и:
$data = $cache->get($key);
if ($data === false) {
$data = $this->calculateSomething();
$cache->set($key, $data);
}Конфигурация
После продолжительных обсуждений было решено добавить возможность настраивать контейнер зависимостей через основную конфигурацию приложения:
$config = [
'id' => 'basic',
// ...
'container' => [
'definitions' => [
'yii\widgets\LinkPager' => ['maxButtonCount' => 5]
],
'singletons' => [
],
],
];Подробнее об этой возможности можно прочитать в разделе «application configurations» официального руководства.
Ещё немного удобства и синтаксиса
С каждым релизом, чтобы сделать разработку приятней, мы пытаемся сделать ошибки всё более полезными и точными. 2.0.11 не исключение. Теперь ошибка при попытке обратиться к несуществующему компоненту сообщает, что именно это и случилось. Ранее фреймворк ругался на невозможность автоматической загрузки класса.
В контроллер добавлены два метода: asJson() и asXml(). Служат они для отдачи данных в формате JSON и XML соответственно.
Производительность
- Yii избавился от запросов с условиями вида
0=1, которые использовались для связей в AR. - RBAC научился пропускать рекурсивные проверки если роли не присвоены какие-либо разрешения.
- Валидатор unique теперь выбирает только первичные ключи, а не полный набор данных.
Ещё одно улучшение напрямую не влияет на производительность, но определённо поможет её увеличить в приложениях. Мы начали логировать использование памяти и процесс сопоставления роутов. Ожидайте соответствующих панелей в следующем релизе модуля debug.
Базы данных
В yii\db\Query добавлены три новых метода: filterHaving(), andFilterHaving() и orFilterHaving(). Они похожи на остальные методы filter*, которые добавляют условие только если значение не пусто и обычно используются для различных фильтров.
Класс yii\db\Connection стало приятнее использовать в случае с конфигурациями master-slave:
- Добавлена опция
shuffleMasters, при помощи которой можно отключить случайный выбор master-соединения. - Добавлен метод
getMaster()и свойствоmaster. Они позволяют получить текущее активное master-соединение.
\yii\db\Query теперь можно передавать в insert() как напрямую вторым аргументом, так и в качестве значения одного из параметров:
$db = Yii::$app->db;
// вставляем query
$sourceQuery = new \yii\db\Query()
->select([
'title',
'content',
])->from('{{post_queue}}');
$command = $db->createCommand();
$command->insert('{{post}}', $sourceQuery);
// используем query как значение
$titleQuery = new \yii\db\Query()
->select('title')->from('{{titles}}')->limit(1);
$command = $db->createCommand();
$command->insert('{{post}}', [
'title' => $titleQuery,
'content' => 'Привет!',
]);Совместимость с PHP 7
Мы постоянно проверяем фреймворк на совместимость с PHP 7. К 2.0.11 мы нашли и исправили проблему, связанную с обработкой ошибок и Throwable.
Менеджер URL
При генерации URL через UrlManager::createAbsoluteUrl(), Url::to() или Url::toRoute() теперь можно указать схему как пустую для создания протоколо-независимых URL:
echo Url::to('@web/images/logo.gif', '');
// //www.example.com/images/logo.gifТакже при генерации URL стали не обязательными параметры, для которых существуют значения по умолчанию:
echo Url::to(['post/index', 'page' => 1, 'tag' => '']);
// теперь можно так:
echo Url::to(['post/index', 'page' => 1]);Виджеты
Расширяемость виджетов была значительно улучшена. Добавлены события при инициализации, перед стартом рендеринга и после его завершения. Примеры применения смотрите в описании issue.
Безопасность
В фреймворк было включен фильтр HostControl, при помощи которого можно предотвратить атаку через подмену хоста. В идеале её лучше не допускать правильной конфигурацией веб-сервера, но так как поступило довольно много запросов от тех, кто не имеет доступа к настройке
сервера, решили всё-таки включить данный фильтр в фреймворк. Детально о настройке данного фильтра можно прочитать в руководстве.
Также была найдена и исправлена проблема с экранированием данных на странице ошибки в режиме отладки. Так как проблема не затрагивает рабочие сервера, мы не стали выпускать отдельный патч-релиз.
Инсталлятор Composer
Вместе с релизом фреймворка мы выпускаем новую версию 2.0.5 инсталлера Composer. Этот плагин для Composer отвечает за установку расширений и позволяет обходиться без конфигурации в процессе бутстрапинга. Также он выполняет разные задачи при создании нового проекта. Благодаря Robert Korulczyk, стало возможно выполнять задачи и при composer install, что особенно важно для обработки локальных файлов конфигурации, которые теперь можно копировать при помощи нового метода copyFiles. Более детально можете почитать в README.
Также плагин начал при обновлении пакета yiisoft/yii2 уведомлять о важных изменениях из UPGRADE.md.
Подписанные коммиты и теги
Это первый релиз, с подписанным GPG тегом, что позволяет проверить, что он сделан командой Yii. Позже мы опубликуем детальные инструкции по проверке.
На GitHub подписанные теги можно отличить по надписи "verified": https://github.com/yiisoft/yii2-framework/releases/tag/2.0.11.
Комментарии (89)
gogolinsky
02.02.2017 00:56+1Отличная новость!) Какие дальнейшие планы?
SamDark
02.02.2017 02:04+1Релизы расширений, новый сайт, yiipowered, 2.1.
gogolinsky
02.02.2017 08:02Что такое yiipowered?
russ666999
02.02.2017 13:13+2Yii powered websites showcase
https://github.com/samdark/yiipowered
dimaborisovsky
02.02.2017 16:38А каков собственно функционал этого добра?
SamDark
02.02.2017 16:38+1Будет принимать от всех желающих информацию о проектах, сделанных на Yii, и показывать её.
eskrano
02.02.2017 02:03А когда откажетесь от поддержки php 5.4? Я понимаю что это круто (старые версии и шаред хостинги), но все же…
SamDark
02.02.2017 02:03+1В 2.1.
Arik
02.02.2017 08:01В сторону php 5.6?
sizeg
02.02.2017 13:13А смысл, если уже есть производительный 7?
SamDark
02.02.2017 13:14Фреймворк и сейчас работает отлично на семёрке. И да, быстрее. Рекомендую обновиться, если ещё нет.
Arik
03.02.2017 08:30+1сразу на 7? вроде нижнюю планку обсуждали. Клиенты с простыми сайтами не всегда готовы идти на VPS
zelenin
03.02.2017 13:245.6 уже на security support, т.е. всё.
SamDark
03.02.2017 13:37+1И? Это не наша проблема. Если технически фреймворк работает с 5.4 и проблем ни в поддержке ни в работе с PHP 7 это не вызывает, зачем завышать требования?
zelenin
03.02.2017 13:45-1я не про завышение, а про неразумность выбирать в качестве нового минимума версию, уже снимаемую с поддержки. А повышать или не повышать — дело команды.
SamDark
03.02.2017 15:06Если бы вопрос выбора сопровождался бы написанием тучи polyfill-ов для этой версии, повышали бы до семёрки не задумываясь. А так как уже всё написано, покрыто тестами и работает, смысла нет.
zelenin
03.02.2017 16:23-1Александр, ты продолжаешь о чем-то своем рассуждать. Речь идет о выборе минимально поддерживаемой версии во время предполагаемого перехода в одной из мажорных версий фреймворка. Ни полифиллы ни тесты здесь не причем.
Переход должен быть потому, что 5.4-5.5 уже не поддерживаются даже фиксами безопасности, что создает брешь и в вашем продукте. По этой же причине следующая минимальная версия должна быть поддерживаемой (5.6 на излете).
Mendel
03.02.2017 16:29+3А зачем? Выбор версии софта на сервере это не ответственность фреймворка.
Если он МОЖЕТ работать на старом, то он должен на нем работать.
Допустим у человека сервер завязан на 5.4 и он не может его проапгрейдить потому что на сервере есть другой софт со своими зависимостями. Но прикладного кода не много, и он тривиален, поэтому совместимость с прошлой версией фреймворка сохраняется или легко апдейтится. Разработчик хочет перейти с 2.0 на 2.1. Но тут мы ему такие специально подляну всунули — код может работать на 5.4., но мы решили подумать за него и всунуть ему в композер зависимость на пхп7. Вот с какого перепуга?zelenin
03.02.2017 16:35-1поддержка определенной версии — это не столько вопрос плюшек новых версий, сколько вопрос уверенности пользователя (т.е. разработчика/заказчика) в стабильной его работе на данной версии. Заявляя поддержку версии, которая уже не получает фиксов безопасности, ты подставляешь своих пользователей, т.к. не обеспечиваешь эту самую стабильную работу. Поэтому каждая мажорная версия должна поднимать минимально поддерживаемую фреймворком версию вслед за минимальной поддерживаемой версией php его разработчиком.
Mendel
03.02.2017 17:39+3Это не ответственность фреймворка.
Обновление версии пхп это ответственность админа, хостера, кого угодно, но не фреймворка. Может сервер живет настолько глубоко, что при всем желании и возможности туда не достучаться злому дяде. Но на нем стоит кастомная сборка пхп5.4, с кастомным расширением в виде бинарника, и выпуск этого расширения под пхп7 неизвестно когда будет. При этом юии2.0 будет менее безопасен чем 2.1 (ну возьмем экзотический случай, что мы дожили до снятия с поддержки 2.0, но еще хотим пхп5.4, ну вот сферический конь в вакууме, но мало ли какие будут комбинации). И вы вынуждаете использовать устаревший софт, просто потому что «так нада».
одно дело писать в документации что мол настоятельно рекомендуем обновить пхп, что скоро мы можем прекратить его поддержку и т.п. Но… писать в требованиях не то что надо, а то что кажется верным по религиозным соображениям — моветон.zelenin
03.02.2017 20:10Это не ответственность фреймворка.
это отвественность создателей продукта — поддерживать минимально безопасную экосистему
Но… писать в требованиях не то что надо, а то что кажется верным по религиозным соображениям
вот такой вот уровень дискуссии — представить мнение, которого придерживается большинство мейнетейнеров фреймворков, религиозным, т. е. маргинальным.SamDark
03.02.2017 22:50Безопасность тут не при чём. Смотрите: http://php.net/supported-versions.php
5.6 в плане безопасности поддерживаться будет дольше, чем 7.0.
zelenin
04.02.2017 00:28-1именно. поэтому и выбирать в качестве минимальной можно не 5.6 и 7.0, а 7.1. но с учетом распространения версий и функциональных изменений разумнее будет выбрать 7.0, которую в качестве минимальной выбирают все зарелизенные в последние полгода популярные в комьюнити библиотеки (от symfony/laravel до phpunit). А мы кстати говорим о 2.1, релиз которого вряд ли произойдет ранее второй половины года, а то и вообще не в 2017, судя по прошлой динамике.
SamDark
04.02.2017 15:17Ну чем разумнее-то? У неё поддержка по времени меньше, чем у 5.6. 7.1 — да, разумно выбрать с точки зрения поддержки, но не разумно потому как никто его ещё не использует и массового перехода в ближайший год не будет.
zelenin
04.02.2017 16:00-1одинаковая у нее подержка. разница в 3 недели.
SamDark
04.02.2017 17:04Ну тогда почему обязательно 7, а не 5.6?
zelenin
04.02.2017 17:10-1для стимулирования комьюнити. если бы не было 2.0, то комьюнити до сих пор не знало бы что такое неймспейсы (на форуме и сейчас, в 2017 вылазят люди и говорят, что за неймспейсы вы придумали).
SamDark
04.02.2017 17:12Для стимулирования мы уже написали в гайде "runs best with PHP 7.0+" и на сайте на главной напишем большими буквами. Но требовать это через composer.json, всё-таки, не стоит.
SamDark
04.02.2017 15:20То, что трендово и модно — не отрицаю. Рационально — нет.
zelenin
04.02.2017 16:04-1yii2 — не про энтерпрайз. не стоит поддерживать все старье в новых мажорных версиях.
SamDark
04.02.2017 17:07Ну, если IBM, Facebook, Альфа-групп, мэрия Москвы, минфин Украины, РТРС, FIFA — это всё не enterprise, то хорошо...
zelenin
04.02.2017 17:14-1а) смешно (уверен в этом списке нет ничего кроме визиток и небольших личных кабинетов — про фейсбук например я точно помню, что там было.)
б) никто не говорит о миграциях старых продуктов на новые мажорные версииSamDark
04.02.2017 17:29а) Есть. IBM — сеть моллов в Китае. Альфа-групп — биржа. РТРС — весь интранет с внутренними процессами. FIFA — часть интранета. Facebook, мэрия Москвы, минфин Украины — да, по сути CMS.
б) И как их поддерживать?zelenin
04.02.2017 17:37-1вы и не будете их поддерживать, т.к. вы не энтерпрайз. поэтому когда к вам в issue прибегут с проблемой взломов сайтов на yii2, использующих 5.4.*, вы разведете руками — поддержка 5.4 кончилась. Поэтому в ваших же интересах указывать версии php с более долгим сроком поддержки. Проблема в php, а репутация пострадает ваша.
SamDark
04.02.2017 17:42Если у нас в требованиях будет 5.4, руками мы не будем разводить, а решим проблему, если она решаема PHP-кодом, или поднимем минимальные требования, если нет.
zelenin
04.02.2017 17:50и сломаете обратную совместимость
SamDark
04.02.2017 18:00Ну а какие ещё варианты есть, если её нельзя не сломать?
- Сломать.
- Выпустить новую мажорную версию и задепрекейтить текущую.
По сути это одно и то же. Версионирование только отличается.
zelenin
04.02.2017 18:12Ну а какие ещё варианты есть, если её нельзя не сломать?
при разработке новой мажорной версии выбрать в качестве минимума не 5.6/7.0, а 7.1/7.2.
ломать совместимость — это почти то же самое что ничего не делать, т.к. формально вы предлагаете переписать приложение написанное под одну версию php на другую. У кого-то опытного заработает без допилки, а у кого-то весь код в задепрекейченных в новой версии php функциях. В прицнипе звучит достаточно просто, но формально неправильно.SamDark
04.02.2017 18:22Формальное несоблюдение SemVer да, в этом случае будет. Согласен.
С другой стороны, какова вероятность того, что 2.1 с 5.6 проработает до начала 2019 без проблем? Как по мне, довольно высокая. Выбирать сейчас 7.1, как по мне — отбить охоту использовать фреймворк у тяжеловесов вроде IBM. Согласование мажорные версии у них проходит с большим скрипом как раз под конец официальной поддержки (знаю по Oracle и Siemens). Выбирать 7.0, если отбросить генерацию хайпа и рассматривать только проблемы с безопасностью, бессмысленно.
zelenin
04.02.2017 18:37Выбирать сейчас 7.1
ну когда вы собираетесь 2.1 выкатывать? далеко не сейчас же.
отбить охоту использовать фреймворк у тяжеловесов вроде IBM
ну что они, на шаредах что ли сайты пилят?) сейчас докер очень популярен в т.ч. и у монстров рынка, а через год и того больше.
С другой стороны, какова вероятность того, что 2.1 с 5.6 проработает до начала 2019 без проблем? Как по мне, довольно высокая
ну по мне вероятность довольно высокая чуть ли не на любой версии проработать стабильно разумное кол-во лет. Хоть на 5.4. Но в то же время то одно то другое — curl, openssl, а это все связано.
Mendel
04.02.2017 16:06+1Религиозное это значит «дело вкуса» а не маргинальное.
Про SOLID слышали?)
Шучу, шучу. Понятно что слышали, и вопрос не без сарказма.
Я намекаю на то, что не нужно смешивать ответственности.
У каждого инструмента своя ответственность. И если фреймворк сообщает (в автоматическом виде например композеру или текстом в документации, не суть) что его технические ТРЕБОВАНИЯ такие-то, то этот инструмент предназначен для информирования о технических ТРЕБОВАНИЯХ. Можно отдельно писать рекомендации. Можно делать секьюрети-рассылки. Но не нужно навязывать одному инструменту две функции. В требованиях указывается требование. Всё. Если мы будем засовывать в требования пожелания по безопасности, то мы вернемся к лапше девяностых. Во всём.
ПС: я бы допустил разговор о завышенных требованиях в шаблонах приложений, но точно не во фреймворке.
Ну и комментарий, да. Мол требуем больше чем надо ибо вы ребятки обновляйтесь а не спите.zelenin
04.02.2017 16:21У каждого инструмента своя ответственность. И если фреймворк сообщает (в автоматическом виде например композеру или текстом в документации, не суть) что его технические ТРЕБОВАНИЯ такие-то, то этот инструмент предназначен для информирования о технических ТРЕБОВАНИЯХ. Можно отдельно писать рекомендации. Можно делать секьюрети-рассылки. Но не нужно навязывать одному инструменту две функции.
если я правильно понял, вы против того, чтобы указывать в composer.json зависимости библиотеки — их надо «рекомендовать» в отдельном месте. Либо же вы отделяете зависимости в виде библиотек от зависимости в виде интерпретатора, как будто бы мейнтейнеры должны требовать установки определенных версий библиотек, на которых гарантируется стабильная работа фреймворка, но не должны требовать версию интерпретатора, потому что что-то.SamDark
04.02.2017 17:11+1Если свежая версия интерпретатора по факту не требуется для работы кода, зачем указывать её в composer.json?
zelenin
04.02.2017 17:20для стабильной работы. вы не поддерживаете php и сторонние либы, поэтому указываете те версии, на которых гарантируете стабильную работу фреймворка. Либо сами пишите патчи для зависимостей. Вы не энтерпрайз, поэтому непонятно почему вы не можете более свободно относиться к зависимостям, не ломая совместимости в рамках семвера.
Если сейчас было бы уместно указать 5.6/7.0, то к моменту выхода 2.1 до конца поддержки останутся месяцы, дай бог год.SamDark
04.02.2017 17:31Именно. Не требуется 7.0 для стабильной работы. Мы гарантируем, что 2.1 работает прекрасно на 5.6. Если в процессе разработки 2.1 потребуется технически 7.0 или найдут фатальный недостаток в 5.6, выставим в зависимостях 7.0.
zelenin
04.02.2017 17:45поэтому сообщество зенда, симфони, ларавела будет всегда профессионально развитее, а сообщество yii2 будет состоять из динозавров.
Симфони/Ларавел УЖЕ на 7.0. Зенд УЖЕ на 5.6. PhpUnit6 уже на 7.0. Большинство библиотек из обзора php-новостей на хабре УЖЕ на 7.0. А мы обсуждаем с кор девелопером yii 5.6 или 7.0 выбрать ЧЕРЕЗ ГОД.SamDark
04.02.2017 17:57Ну как уже, когда Laravel только собирается, Symfony — не ранее ноября. PHPUnit поднял версию ради поднятия версии. Просто потому что все прыгают и я прыгну. Технически в этом необходимости не было. Теперь будут поддерживать несколько веток.
Профессионально развитее потому что фреймворк не работает на 5.6 и при этом не использует ничего из 7.0? Да ладно вам. Я бы ещё понял если бы аргументом была большая степень абстракции или меньшая связанность, но не это...
zelenin
04.02.2017 18:07Ну как уже, когда Laravel только собирается, Symfony — не ранее ноября.
да, ок был не прав. казалось, 3.3 уже вышла. Но тенденция ясна.
Технически в этом необходимости не было
да и не должно быть. Вы не энтерпрайз. Вам надо хайп ловить, привлекать новых членов комьюнити за счет трендов и баззвордов.SamDark
04.02.2017 18:26+2Мне очень не хотелось бы в PHP видеть ту же картину, что и в JavaScript: новый тренд каждые два месяца. Начинаем делать проект на трендовом фреймворке, к релизу он уже безбожно "устарел" и не поддерживается официально. Одно дело программировать ради фана и просто забивать на любую поддержку, и совсем другое — делать основу, на которой строятся и поддерживаются годами отличные проекты.
Mendel
05.02.2017 10:12+1Новые тренды ради новых трендов и академичность ради академичности. Главные болячки мейнстрима среди проф.решений.
В этом же контексте выплывает другая проблема — меняющиеся как кадры фильма версии без обратной совместимости не дают полноценно вырасти стабильной экосистеме.
Не поймите меня превратно. Вордпресс безнадежно устарел, и да, я никогда не считал его фреймворком в отличии от многих ВПфилов. Но его устаревание и его популярность это две стороны одного явления — преемственности. При всем желании ВП не может перейти на ООП, MVC и т.п. Он потеряет совместимость и перестанет быть ВП. Не ратую за то, чтобы застревать в девяностых как ВП, но понимать чего стоит гонка за модой тоже нужно.
Mendel
05.02.2017 09:59В зависимостях должны указываться зависимости. Это понятно?
Юии зависим от 5.4, значит надо указать его зависимость — 5.4.
Библиотеки тянутся с гитхаба одинаково хорошо, что старые, что новые, так что мешать не стоит. Плюс опять таки — минорную версию лучше указывать ту которая реальная зависимость, ведь компостер сам подтянет тебе посвежее из совместимого и стабильного.
Нет, хотите строгости и паранойи? Я вас понимаю. Глядя как в первом Юии (со вторым плотно не работал, только в уже готовое что-то дописывал, так что не слежу) половина вечно забывала включить проверку XSRF у себя я делаю такие вещи по умолчанию, а если хочешь без них, то отдельно отключай. Хотите паранойю — сделайте отдельную библиотеку, назовите ее например секьюритиТест или секьюритиПак, туда пристройте все зависимости, все строгости, все проверки и замечания. Так будет ок, так будет СОЛИДно. :)
Mendel
03.02.2017 16:25+2Полностью поддерживаю. Сам в свое время перешел на 5.4 только потому что задолбался с array(). По факту конечно скорее всего есть и другие зависимости от 5.4., но когда требование на 5.4 уже есть, то дальше уже не смотришь. А всё остальное (почти всё) некритично, и стараешься писать слишком не злоупотребляя свежатиной, а когда основной костяк уже написан, то и поддерживать обратную совместимость не приходится особо. Старый код УЖЕ есть. Чисто под проект можно вводить более свежие зависимости, но ядро то зачем?
Djeux
02.02.2017 13:14+1Только queue модуля не хватает для полного счастья.
SamDark
02.02.2017 13:14Когда-нибудь и его допилим.
Djeux
02.02.2017 13:18+1Я уже себе допилил github.
Могу помочь или просто перенести в официальный пакет если есть интерес.SamDark
02.02.2017 13:52Да так много кто сделал. В issue https://github.com/yiisoft/yii2-queue есть ссылки.
vlasenkofedor
03.02.2017 14:40Пожалуйста прокомментируйте этот код
$data = $cache->getOrSet($key, function () { return $this->calculateSomething(); });
Почему вы считаете передачу методу параметром анонимной функции обратного вызова
Появился удобный синтаксис
padlyuck
03.02.2017 14:55+2Меньше буковок печатать.
Код выше делает то же, что и:
$data = $cache->get($key); if ($data === false) { $data = $this->calculateSomething(); $cache->set($key, $data); }
А чем вас смущает новый синтаксис? Никто не запрещает по-старинке расписать все явно.
vlasenkofedor
03.02.2017 15:01-2Меня не смущает и абсолютно не интересует, что делает код.
Я спрашиваю где здесь удобство синтаксиса
Как по мне удобство синтаксиса
$data = $cache->getOrSet($key);SamDark
03.02.2017 15:13+1А данные откуда брать, если в кеше их не оказалось?
vlasenkofedor
03.02.2017 15:23-2если в кеше их не оказалось
null, false
и это к реализации
вы же привели пример в качестве удобного синтаксиса
вот про синтаксис и говоримSamDark
03.02.2017 15:41+2Вы привели совсем не эквивалент. То, что у вас — это обычный
$cache->get, который в таком виде уже давно существует. То, что в релизе — это getOrSet. То есть попробовать получить из кеша и, в случае отсутствия, вычислить и сунуть в кеш.
vlasenkofedor
03.02.2017 15:53Вы можете написать реализацию без callback
Код будет читабельный, редактор будет воспринимать
Вы же привели частный случай и описали как некое удобство.
Нет здесь удобства, функция анонимная вместо именной. Обратный вызов без которого легко обойтись.
BoShurik
03.02.2017 16:31+2Как обойтись без обратного вызова?
Если
$data = $cache->getOrSet($key, $this->calculateSomething());
То эквивалентом будет
$default = $this->calculateSomething(); $data = $cache->get($key); if ($data === false) { $data = $default; $cache->set($key, $data); }
Только в таком случае кеш бесполезен
vlasenkofedor
03.02.2017 18:06Как обойтись без обратного вызова?
Просто
class Cache { private $storage = []; public function get($key) { return $this->storage[$key] ?? null; } public function set($key, $value) { $this->storage[$key] = $value; return $value; } } $cache = new Cache(); $result = $cache->get('Igor') ?? $cache->set('Igor', 20); var_dump($result);
Вы опять про реализацию, а я про синтаксис спрашивалpadlyuck
03.02.2017 18:24+1<irony> хоспади, люди просто добавили сахара, чего ж вы к синтаксису приклепались?)) </irony>
Zhuravljov
03.02.2017 18:28+1А что не так с синтаксисом? Самый удобный вариант. Вы приводите пример с готовым значением
20. А где и как вы его будете получать? Вот именно этим и будет заниматься колбэк, если в кеше еще нет готового значения.
Наиболее распространенный кейс использования кэша:
if (($value = $cache->get($key)) === false) { // Тут код ресурсоемкой операции, результат которой нужно закэшировать $value = 123; $cache->set($key, $value); }
Теперь можно так:
$value = $cache->getOrSet($key, function () { // Код операции, результат которой нужно закешировать return 123; });vlasenkofedor
03.02.2017 18:39А что не так с синтаксисом?
Хорошая манера вопросом на вопрос отвечать
Вы приводите пример с готовым значением 20
$value = $cache->get($key)?? $cache->set($key, $this->calculateSomething());
Считаю, что код в одну строку, лучше читаем и понятен
x000000
03.02.2017 18:44В кеше вполне может быть значение null и в этом случае ваш код будет всегда перекешировывать этот null. В «удобном» же варианте такого не должно происходить. Да и set метод скорее всего возвращает void.
vlasenkofedor
03.02.2017 18:53В кеше вполне может быть значение null
И что? Внимательно читайте посты пожалуйста.
Вы уже второй человек который у меня спрашивает про реализацию.
Вопрос былЯ спрашиваю где здесь удобство синтаксиса
За минусы спасибо. Прикольно когда за спрос бъютZhuravljov
03.02.2017 22:29+1Вам объясняют что, тот вариант, в одну строку, который вы предлагаете, не рабочий. И, чтобы его рабочим сделать, одной строки не хватит.
get()может вернутьnull, аset()возвращает результат записи в кэш, а не значение, которое вы туда пишите.
Удобство в том, что
\yii\caching\Cache::getOrSetуниверсальный метод, который корректно покрывает наиболее распространенный кейс.
Единственное, если бы параметр
\Closure $closureне стали бы делать типизированным, было бы проще. Тогда вариант в одну строку с вашей функцией мог бы выглядеть так:
$value = $cache->getOrSet($key, [$this, 'calculateSomething']);
Но и с анонимной функцией вполне удобно:
$value = $cache->getOrSet($key, function () { return this->calculateSomething(); });
С читабельностью все в порядке. Не пойму что именно вас смущает? Анонимные функции?
Минусы не мои.
vlasenkofedor
03.02.2017 23:40в вашем варианте тогда get при false считается невалидным, что если результат надо закешировать false. Почему я выбрал null
ей еще не было присвоено никакого значения
Почему set вернул значение, да потому, что это удобно в синтаксисе. Не только возвращать this для вызовов цепочкой, но и value иногда в set пример от fatfree
Чтоб не говорили, что мой код не рабочий. (php7)
Песочница 1
$result = $cache->get('Igor') ?? $cache->set('Igor', query());
Песочница 2
$result = $cache->get('Igor', $cache->set('Igor', query()));
set() возвращает результат записи в кэш
В примере приведенном в статье автором set ничего не возвращает
И теперь о главном, мой вопрос звучал о синтаксисе, а не о реализации.padlyuck
04.02.2017 00:44+1вы про абстрактный кеш в вакууме, а мы про кеш в yii2. сдается мне, что вы не до конца разглядели как и что возвращает кеш в yii. Ваши примеры имеют право на жизнь и они даже местами приятны взору, но разговор опять же о yii2
Caravus
Спасибо. И за фреймворк и за новость.