Комментарии 41
В очередной раз спасибо за дайджест!
Немношк актуализации:
Slim 4.0.0
Почти следом, 6 августа, вышел релиз 4.1.0
Хотелось бы добавить свои пять копеек, для тех, кто использует связку Phalcon + Redis.
Во время последнего обновления до php7.3.8, обновился и модуль php-redis до версии 5.02. И в этом обновлении метод redis->settimeout признан deprecated, с рекомендацией использовать метод redis->expire. Соответственно если хотим обновиться до выхода новой версии Phalcon – можно/нужно поправить Phalcon\Cache\Backend\Redis->_connect. А если используете сессии на Redis то еще и в конструкторе Phalcon\Session\Adapter\Redis->__construct в качестве redis указать обновленный Phalcon\Cache\Backend\Redis
namespace Kernel\Extend;
use \Kernel\Extend\CacheBackendRedis as Redis;
use \Phalcon\Cache\Frontend\None as FrontendNone;
class SessionAdapterRedis extends \Phalcon\Session\Adapter\Redis {
public function __construct(array $options = []) {
if(!isset($options['host'])) {
$options['host'] = '127.0.0.1';
}
if(!isset($options['port'])) {
$options['port'] = 6379;
}
if(!isset($options['persistent'])) {
$options['persistent'] = false;
}
$lifetime = $options['lifetime'] ?? null;
if($lifetime) {
$this->_lifetime = $lifetime;
}
$this->_redis = new Redis(
new FrontendNone(['lifetime' => $this->_lifetime]),
$options
);
session_set_save_handler(
[$this, "open"],
[$this, "close"],
[$this, "read"],
[$this, "write"],
[$this, "destroy"],
[$this, "gc"]
);
$this->setOptions($options);
}
}
CacheBackendRedis.php
<?php
namespace Kernel\Extend;
use \Library\Redis;
use \Phalcon\Cache\Exception;
class CacheBackendRedis extends \Phalcon\Cache\Backend\Redis {
public function _connect() {
$host = $this->_options['host'] ?? null;
$port = $this->_options['port'] ?? null;
$persistent = $this->_options['persistent'] ?? null;
$redis = new Redis;
if(!$host || !$port || is_null($persistent)) {
throw new Exception("Unexpected inconsistency in options");
}
if($persistent) {
$success = $redis->pconnect($host, $port);
} else {
$success = $redis->connect($host, $port);
}
if(!$success) {
throw new Exception("Could not connect to the Redisd server ". $host .":". $port);
}
$auth = $this->_options['auth'] ?? null;
if($auth && !empty($auth)) {
$success = $redis->auth($auth);
if(!$success) {
throw new Exception("Failed to authenticate with the Redisd server");
}
}
$index = $this->_options['index'] ?? null;
if($index && $index > 0) {
$success = $redis->select($index);
if(!$success) {
throw new Exception("Redis server selected database failed");
}
}
$this->_redis = $redis;
}
}
Redis.php
<?php
namespace Library;
class Redis extends \Redis
{
public function settimeout($lastkey, $tt1) {
return $this->expire($lastkey, $tt1);
}
}
В новом P++ можно будет реализовать массу революционных улучшений, очистить от легаси, и навести порядок не думая об обратной совместимости
Ну наконец-то! Я думаю всем языкам со временем так надо делать (например каждые 20 лет), ато из-за проблем обратной совместимости, с годами накапливается просто куча мусора в кодовой базе, от которого никак не избавиться.
Ну или как сказал коллега выше, не поддерживать обратную совместимость в каждой новой мажорной версии.
Вряд ли такое кто-то будет осознанно использовать в работающем коде, но при тестировании часто встречается ситуация, где не плохо было бы либо прочитать значение из скрытого поля или наоборот туда что-либо записать.
p.s. Да-да, я знаю, что если очень хочется так сделать, то что-то не так с архитектурой и тестировать надо публичный контракт класса, а не его кишки, но жизнь штука многогранная и иногда приходится делать и такие трюки.
- Тестирование.
- Гидрация.
А что насчет P++ -> Q++ это вкусовщина. Не так уж и важно что и как мы называем, главное чтобы было понятно как и зачем с этим работать. Когда Расмус начал писать PHP он не думал и не мечтал что эта поделка превратится в полноценный язык программирования и будет так востребован через 25 лет. Что будет еще через 10 — время покажет.
Мне кажется не стоит обосновывать сегодняшние решения какими-то абстрактными аргументами. Есть вполне конкретные аргументы почему хочется сделать отдельный диалект и есть аргументы почему это не так просто как хотелось бы. Было бы просто, вопрос бы не стоял. И основной вопрос это в первую очередь ресурсы.
Ресурсы найдутся я думаю только если кто-то большой скажет что ему это нужно. Но я в этом сомневаюсь. К сожалению, последние лет 5, несмотря на прорыв с PHP 7, индустрия в целом не смотрит на PHP. Все ушли в Java, Python, NodeJS, Go etc. PHP не спеша, но закапывают в землю. Это грустно наблюдать. Поэтому я думаю у ребят не хватит сил поднять и тащить еще один диалект. Думаю они все же просто станут отрезать легаси в основной ветке с каждым релизом. Этого достаточно для коммьюнити.
Вы заодно походя оскорбили основную команду разработчиков и ментэйнеров, которые отрезали огромную часть легаси при переходе на PHP 7 и явно не собираются сдаваться и менять свое мнение в этом направлении.
А насчет тонн работающего кода, зачастую при наличии воли, рефакторинг занимает не так много времени и позволяет начать экономить время и ресурсы вообще. Не так страшен черт как его малюют.
Есть такие золотые слова «обратная совместимость». И в энтерпрайзе это особенно важно.
То что горящие пылкие юноши мечтают каждый год всё переписывать заново и бесплатно (если это свои проекты, или рабочие, но это никто не оплатит), потому что всё сломалось и обратной совместимости нет — что ж, пусть занимаются этим мазохизмом, только пожалуйста в другом языке.
Попытаюсь донести до вас свою позицию. И в чем она отличается от вашей. Отбросив эмоциональные и бессмысленные по сути высказывания имеем ваш аргумент:
… переделки ради мифической «красоты». Работает — не трожь.
… «обратная совместимость».
Отвечаю по пунктам:
— Ради мифической красоты не надо ничего переделывать. Если вы или я не знаю зачем я что-то переделываю, то я с вами тут легко соглашусь, не надо ничего переделывать. Но на практике вы или такие как вы, или то как я понимаю кто вы :-) используют этот аргумент чтобы «ничего не трогать». Например имеем спагетти модели данных или даже то что трудно назвать моделями, все написано в разное время разными разработчиками, какие-то куски похожи друг на друга, какие-то нет. И трогать эту всю «красоту» никому не хочется. Только вот на мой взгляд стОит это переписать чтобы все было понятно и однообразно и желательно с использованием лучших паттернов программирования и с учетом требований безопасности. Потому что это сократит время на onboarding, сократит время на отладку и отлавливание любых видов багов, позволит применять нормальные методы тестирования и учета зависимостей, увеличит производительность, и в итоге сократит расходы на поддержание в разы, а может и в десятки раз. Так же хороший код позволяет притягивать и удерживать грамотных специалистов в проекте и поднимать уровень молодежи, которая впитывает бест практисес каждый день, вместо того чтобы привыкать и считать что легаси — это норма. И упаси боже если молодежь решит что (подставлять костыли повсюду) это лучшее что они могут делать в их жизни.
— Работает — не трожь. Тот же ответ что и с предыдущим пунктом. Я полностью согласен, что если что-то работает — не надо это трогать. Только в жизни зачастую люди считают что-то неработающее чем-то работающим. И чаще всего все это легаси не работает, а перманентно глючит и команда постоянно отвлекается и занята поиском причин почему оно глючит или отваливается раз в неделю. видал я такие проекты где решением была перезагрузка сервера по ночам, чтобы не искать причину таких глюков. Так что да если что-то работает, трогать не надо, а вот если к вам второй раз пришел запрос на поиск причин инцидента с какой-то подсистемой и вы знаете что истинная причина кроется в легаси, то я бы поднимал вопрос и начинал планировать рефакторинг.
— обратная совместимость Не совсем понимаю о чем вы. Все паттерны известны и нет никакой проблемы с обратной совместимостью PHP кода. Есть недостаток знаний и опыта как это правильно мигрировать.
Но вы можете оставаться при своем мнении. Дело хозяйское. Просто меня цепляет ваша категоричность и эмоциональность. Особенно отсылка к «пылким юношам», как-то смешно звучит.
Вот у меня другие ощущения, что 95% хотели бы убрать легаси. И лишь 5% ретроградов прикрываясь глупостью "работает — не трожь" ничего не хотят делать.
https://externals.io/message/106453#106477 — скорее всего, большинство будет солидарно с этим письмом.
Спасибо, посмеялся. Люди были бы happy после upgrades, если бы у них никогда ничего не ломалось, а просто добавлялась бы производительность и новые возможности. В нормальном энтерпрайзе так и должно быть. PHP же стараются постоянно сместить на дорожку несовместимости Python 2/3.
>>Tooling was available to automate transitions.
Спасибо, тоже посмеялся. Куча разразнённых тул, ни одной полностью официальной, и всё равно находит лишь часть несовместимостей. Например ни одна тулза даже не знала о поломке htmlspecialchars в 5.4, когда для кириллициы оно по дефолту начало возвращать пустоту. Ни одна тулза не имеет автоматического режима с одной кнопкой FixAll, которая бы сама гарантированно и работоспособно всё исправила, а значит требуется всё равно много времени ручного труда, дебага, проверок и тестов.
Я согласен с его высказыванием, что нет смысла удалять <?, потому что и так есть short_tags=off для тех кто это не хочет.
Если я правильно понимаю, P++ как раз не ломает обратную совместимость. Здесь похоже на связку Java + Kotlin: вы можете пользоваться Legacy-библиотеками, но при этом свой проект уже писать на новом диалекте. При этом, переводить на новый диалект проект можно будет поэтапно. И наоборот: можно писать на старом PHP, но использовать при этом новые библиотеки на P++.
Это вполне может получиться, но зависит от «вкусности» нового диалекта для разработчиков. Например, меня может соблазнить переработка стандартной библиотеки, и например замена стандартных функций работы с массивами на что-то типа
[1,2,3].push(4)
. Но рисков тоже очень много.
Думаю, не сопротивлялись бы и добавили возможность внедрять код напрямую в Zend VM — появилась бы куча уже диалектов (привет JVM). Само появление Hack Lang — это одна из причин отсутствия оного функционала.
А то в текущем варианте можно лишь патчить опкеш, что является чуть-чуть извращением. Ну и переписывать/кодогенерировать сырцы (Yay, Preprocess, Symfony, Doctrine, Go!, e.g.).
навести порядок не думая об обратной совместимости
не сильно заметно, чтобы о ней много думали ранее.
PHP-Дайджест № 162 (1 – 12 августа 2019)