Pull to refresh

Comments 41

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

Думаю, лучше продемонстрировать кодом:
SessionAdapterRedis.php
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++ такое себе) Мне нравится подход с declare, хочешь включаешь типизацию, хочешь — нет. Но еще больше мне нравится подход, как с тем же Angular, выходит новый фреймворк, обновляей систему или сиди на старой. Не вижу проблем, почему нельзя выпускать новые релизы PHP, без саппорта легаси, пусть легаси сидит на старых версиях.
UFO just landed and posted this here
Вероятно, мсье никогда не работал с проектом с кодовой базой возрастом 15+лет
В новом P++ можно будет реализовать массу революционных улучшений, очистить от легаси, и навести порядок не думая об обратной совместимости

Ну наконец-то! Я думаю всем языкам со временем так надо делать (например каждые 20 лет), ато из-за проблем обратной совместимости, с годами накапливается просто куча мусора в кодовой базе, от которого никак не избавиться.

Ну или как сказал коллега выше, не поддерживать обратную совместимость в каждой новой мажорной версии.
Действительно создание нового языка P++ на базе PHP выглядит сомнительной затеей

не потянут. ресурсов и на актуальный php не хватает.

Так уважаемый комментатор высказался что создание языка на базе PHP выглядит сомнительной затеей, а не что сомнительно потому что ресурсов нет. Видно он знает что-то такое что помешает родиться хорошему языку(одному из тысяч :)).
А зачем нужна вся эта история с получением доступа к приватным пропертям без рефлексии? Каков use case использования этого трюка в реальном продакшене?

Вряд ли такое кто-то будет осознанно использовать в работающем коде, но при тестировании часто встречается ситуация, где не плохо было бы либо прочитать значение из скрытого поля или наоборот туда что-либо записать.


p.s. Да-да, я знаю, что если очень хочется так сделать, то что-то не так с архитектурой и тестировать надо публичный контракт класса, а не его кишки, но жизнь штука многогранная и иногда приходится делать и такие трюки.

Спасибо за развернутый ответ! Про тестирование приватных пропертей я понял. Только почему именно «без рефлексии»? Мы тестируем что-то в PHP 4, где нет рефлексии? Ну так там и нету closures! «Рефлексия — это медленно!». Лишняя секунда (ок, 10 секунд!) на выполнение тестов причиняет такие велики боль и страдания, что надо вот заморачиваться с хитрыми трюками? Это не к Вам, levchik, вопрос. Это так просто, мысли вслух. Еще раз спасибо за ответ!

Думаю, что это просто один из подходов решения проблемы, а уж что использовать — выбирает каждый сам для себя. Мне тоже ближе использовать замыкания, чем рефлексию, не потому что быстрее или еще что-либо, а просто потому что больше нравится запись.

Для меня есть один валидный повод тестить с использованием рефлексии — это если тестируемый код работает с использованием рефлексии. Например какие-нибудь хитрые дата-мапперы или десериалайзеры, которые устанавливают значения напрямую в проперти. В этом случае вполне валидно подсмотреть рефлексией, что там установлено
UFO just landed and posted this here

Весь autowire тоже построен на рефлексии.

UFO just landed and posted this here
  1. Тестирование.
  2. Гидрация.
UFO just landed and posted this here
Подскажите как помочь с добавлением соответствующие аннотации? Есть желание, но чот не пойму как я могу помочь)
UFO just landed and posted this here
UFO just landed and posted this here
Может я что-то упускаю, но мне кажется что говорить что Java это продолжение С не совсем корректно. Все же Java подразумевает дополнительный слой в виде JVM чем обеспечивается кроссплатформенность и универсальность кода. В то время как С и С++ классические компилируемые языки подразумевающие возможность написания кода под определенный процессор и вообще железо с соответствующим уровнем понимания всех нюансов как аппаратной части так и логической (к примеру сборка мусора).
А что насчет P++ -> Q++ это вкусовщина. Не так уж и важно что и как мы называем, главное чтобы было понятно как и зачем с этим работать. Когда Расмус начал писать PHP он не думал и не мечтал что эта поделка превратится в полноценный язык программирования и будет так востребован через 25 лет. Что будет еще через 10 — время покажет.
Мне кажется не стоит обосновывать сегодняшние решения какими-то абстрактными аргументами. Есть вполне конкретные аргументы почему хочется сделать отдельный диалект и есть аргументы почему это не так просто как хотелось бы. Было бы просто, вопрос бы не стоял. И основной вопрос это в первую очередь ресурсы.
Ресурсы найдутся я думаю только если кто-то большой скажет что ему это нужно. Но я в этом сомневаюсь. К сожалению, последние лет 5, несмотря на прорыв с PHP 7, индустрия в целом не смотрит на PHP. Все ушли в Java, Python, NodeJS, Go etc. PHP не спеша, но закапывают в землю. Это грустно наблюдать. Поэтому я думаю у ребят не хватит сил поднять и тащить еще один диалект. Думаю они все же просто станут отрезать легаси в основной ветке с каждым релизом. Этого достаточно для коммьюнити.
Коммьюнити, а именно сами разработчики, не хотят вырезать легаси. Это хотят лишь некоторые больные на голову мазохисты/максималисты/шизофреники, которым не надо поддерживать тонны работающего кода.
Я разработчик. Я хочу вырезать легаси. Возможно я «больные на голову мазохисты/максималисты/шизофреники». Но мне кажется я просто не такой как вы. Может не стоит разбавлять свою речь опосредованными ярлыками не подтвержденными профессиональным мнением и техническими аргументами?
Вы заодно походя оскорбили основную команду разработчиков и ментэйнеров, которые отрезали огромную часть легаси при переходе на PHP 7 и явно не собираются сдаваться и менять свое мнение в этом направлении.
А насчет тонн работающего кода, зачастую при наличии воли, рефакторинг занимает не так много времени и позволяет начать экономить время и ресурсы вообще. Не так страшен черт как его малюют.
Да в гробу 95% разработчиков видели все эти переделки ради мифической «красоты». Работает — не трожь.
Есть такие золотые слова «обратная совместимость». И в энтерпрайзе это особенно важно.
То что горящие пылкие юноши мечтают каждый год всё переписывать заново и бесплатно (если это свои проекты, или рабочие, но это никто не оплатит), потому что всё сломалось и обратной совместимости нет — что ж, пусть занимаются этим мазохизмом, только пожалуйста в другом языке.
Повторюсь, мы с вами разные. И стиль вашего изложения скорее подходит к «горящие пылкие юноши». А ко мне это как раз не относится, вы уж извините, но я уже давно не юноша. Так что ваши эмоциональные вставки снова разбиваются о реальность. Нелюбовь к легаси и любовь к стройности кода, скорее все же присуща опытным и грамотным разработчикам, чем юношам. И снова, как пример, команда разработчиков PHP. Их тоже трудно назвать юношами и уж тем более пылкими.

Попытаюсь донести до вас свою позицию. И в чем она отличается от вашей. Отбросив эмоциональные и бессмысленные по сути высказывания имеем ваш аргумент:
… переделки ради мифической «красоты». Работает — не трожь.
… «обратная совместимость».

Отвечаю по пунктам:
Ради мифической красоты не надо ничего переделывать. Если вы или я не знаю зачем я что-то переделываю, то я с вами тут легко соглашусь, не надо ничего переделывать. Но на практике вы или такие как вы, или то как я понимаю кто вы :-) используют этот аргумент чтобы «ничего не трогать». Например имеем спагетти модели данных или даже то что трудно назвать моделями, все написано в разное время разными разработчиками, какие-то куски похожи друг на друга, какие-то нет. И трогать эту всю «красоту» никому не хочется. Только вот на мой взгляд стОит это переписать чтобы все было понятно и однообразно и желательно с использованием лучших паттернов программирования и с учетом требований безопасности. Потому что это сократит время на onboarding, сократит время на отладку и отлавливание любых видов багов, позволит применять нормальные методы тестирования и учета зависимостей, увеличит производительность, и в итоге сократит расходы на поддержание в разы, а может и в десятки раз. Так же хороший код позволяет притягивать и удерживать грамотных специалистов в проекте и поднимать уровень молодежи, которая впитывает бест практисес каждый день, вместо того чтобы привыкать и считать что легаси — это норма. И упаси боже если молодежь решит что (подставлять костыли повсюду) это лучшее что они могут делать в их жизни.
Работает — не трожь. Тот же ответ что и с предыдущим пунктом. Я полностью согласен, что если что-то работает — не надо это трогать. Только в жизни зачастую люди считают что-то неработающее чем-то работающим. И чаще всего все это легаси не работает, а перманентно глючит и команда постоянно отвлекается и занята поиском причин почему оно глючит или отваливается раз в неделю. видал я такие проекты где решением была перезагрузка сервера по ночам, чтобы не искать причину таких глюков. Так что да если что-то работает, трогать не надо, а вот если к вам второй раз пришел запрос на поиск причин инцидента с какой-то подсистемой и вы знаете что истинная причина кроется в легаси, то я бы поднимал вопрос и начинал планировать рефакторинг.
обратная совместимость Не совсем понимаю о чем вы. Все паттерны известны и нет никакой проблемы с обратной совместимостью PHP кода. Есть недостаток знаний и опыта как это правильно мигрировать.
Но вы можете оставаться при своем мнении. Дело хозяйское. Просто меня цепляет ваша категоричность и эмоциональность. Особенно отсылка к «пылким юношам», как-то смешно звучит.

Вот у меня другие ощущения, что 95% хотели бы убрать легаси. И лишь 5% ретроградов прикрываясь глупостью "работает — не трожь" ничего не хотят делать.
https://externals.io/message/106453#106477 — скорее всего, большинство будет солидарно с этим письмом.

>>lot of people ended up quite happy after doing the upgrades
Спасибо, посмеялся. Люди были бы happy после upgrades, если бы у них никогда ничего не ломалось, а просто добавлялась бы производительность и новые возможности. В нормальном энтерпрайзе так и должно быть. PHP же стараются постоянно сместить на дорожку несовместимости Python 2/3.

>>Tooling was available to automate transitions.
Спасибо, тоже посмеялся. Куча разразнённых тул, ни одной полностью официальной, и всё равно находит лишь часть несовместимостей. Например ни одна тулза даже не знала о поломке htmlspecialchars в 5.4, когда для кириллициы оно по дефолту начало возвращать пустоту. Ни одна тулза не имеет автоматического режима с одной кнопкой FixAll, которая бы сама гарантированно и работоспособно всё исправила, а значит требуется всё равно много времени ручного труда, дебага, проверок и тестов.

Я согласен с его высказыванием, что нет смысла удалять <?, потому что и так есть short_tags=off для тех кто это не хочет.
Не совсем понял вашу позицию, так как это письмо как раз против P++ (по крайней мере то, что прямо по ссылке).

Если я правильно понимаю, P++ как раз не ломает обратную совместимость. Здесь похоже на связку Java + Kotlin: вы можете пользоваться Legacy-библиотеками, но при этом свой проект уже писать на новом диалекте. При этом, переводить на новый диалект проект можно будет поэтапно. И наоборот: можно писать на старом PHP, но использовать при этом новые библиотеки на P++.

Это вполне может получиться, но зависит от «вкусности» нового диалекта для разработчиков. Например, меня может соблазнить переработка стандартной библиотеки, и например замена стандартных функций работы с массивами на что-то типа [1,2,3].push(4).

Но рисков тоже очень много.

P++ был бы хорош, если бы на него были ресурсы. А на него ресурсов нет.
Соответственно, видятся варианты в виде LTS или настроек вроде declare(strict_types=1)/short_tags = On/Off.
Но то, что php отстает от мейнстрима все сильнее — очевидно, и с этим надо что-то делать.

UFO just landed and posted this here
UFO just landed and posted this here
Посоветуйте пожалуйста что нибудь дельное почитать о перезагрузке, очень заинтересовало. Кто уже применяет в реальных условиях?

Думаю, не сопротивлялись бы и добавили возможность внедрять код напрямую в Zend VM — появилась бы куча уже диалектов (привет JVM). Само появление Hack Lang — это одна из причин отсутствия оного функционала.


А то в текущем варианте можно лишь патчить опкеш, что является чуть-чуть извращением. Ну и переписывать/кодогенерировать сырцы (Yay, Preprocess, Symfony, Doctrine, Go!, e.g.).

А в чем сопротивление? Это же все опенсорс. Вроде каждый может делать все что ему вздумается.
появилась бы куча уже диалектов

Вы так говорите, будто это что-то хорошее.

«История одного бага в Laravel Shift» — не история одного бага, а просто подборка фишек.
Поправил, спасибо за замечание!
навести порядок не думая об обратной совместимости

не сильно заметно, чтобы о ней много думали ранее.

Sign up to leave a comment.

Articles