PHP-Дайджест № 184 (6 – 20 июля 2020)


    Свежая подборка со ссылками на новости и материалы. В выпуске: Что будет с поддержкой PHP на Windows, PHP 8 Alpha 2, ReactPHP — официально продакшн-реди, 2 новых RFC предложения и 6 на голосовании, порция полезных инструментов, статьи, видео и подкасты.

    Приятного чтения!



    Новости и релизы


    • PHP 8.0.0 Alpha 2 — Заморозка фич запланирована на 4 августа. Учитывая регламент с 2-недельным обсуждением и голосованием, это значит, что добавиться могут только фичи, которые уже в обсуждении/голосовании.
    • PHP 7.4.8, PHP 7.3.20, PHP 7.2.32 — Секьюрити релизы для Windows, исправляющие уязвимость CVE-2020-8169 в libcurl. Для прочих систем — обычный багфикс.
    • PHP Russia 2020, 29 ноября, Москва — Дату и место определили — отметим релиз PHP 8 вместе!
    • Microsoft, Windows и поддержка PHP — Сначала представитель Microsoft написал, что компания продолжит поддерживать разработку и сборку PHP под Windows для версий 7.2, 7.3 и 7.4 до тех пор, пока они официально поддерживаются. Но не будет поддерживать разработку PHP для Windows начиная с версии 8.0.

      Позже он уточнил, что Microsoft предоставляла билд-инфраструктуру для сообщества PHP, а после ежегодного пересмотра бюджетов решили, что не будут этого делать. И хотя они больше не будут заниматься билдами PHP для Windows, тем не менее, останутся вовлечены в PHP, продолжат поддерживать PHP-разработчиков и сотрудничество с сообществом по секьюрити-фиксам.

      Это подтвердил Joe Watkins, который вместе с Никитой и настраивал все пайпланы в Azure:

    PHP Internals


    PHP 8.0



    Целая пачка предложений находится на стадии голосования и, похоже, все пройдут:


    PHP 8.1


    • [RFC] Deprecations for PHP 8.1 — Несколько возможностей предлагается объявить устаревшими. Сначала изменения предлагалось внести изменения в PHP 8.0, но Nikolas Grekas посоветовал сделать релиз 8.0 без депрекейшнов, по аналогии с *.0 релизами Symfony.
    • [RFC] Objects can be declared falsifiable — В RFC предлагается добавить новый интерфейс Falsifiable с магическим методом __toBool(), который позволит объектам определять и объявлять себя истинными или ложными и соответственно использоваться как bool во всех подходящих контекстах.

      В тему интересная мысль о том, что интерфейсы с суффиксами -able — плохая идея:
    • FFI Improvements — Пока неофициальное предложение от камрада SerafimArts по исправлениям для FFI.
    • В PHP 8.1 планируется EnumIlija Tovilo написал, что планирует реализовать тип Enum в PHP 8.1. А Larry Garfield уже подготовил подробное исследование и сравнил перечисления и подобные им типы в разных языках.

    Инструменты


    • JBZoo/Composer-Diff — Показывает разницу между двумя версиями файла composer.lock, помогает делать подробные changelog'и в MR/PR после «composer update». Прислал smetdenis.
    • JBZoo/Composer-Graph — Визуализация графа зависимости для composer.json.
    • ergebnis/factory-bot — Фабрика фикстур для Doctrine ORM. Подробнее об использовании и мотивации в посте.
    • phpsandbox.io — Аналог codepen/jsfiddle только для PHP. Веб-сайт для быстрого тестирования и демонстрации кода.

    Symfony



    Laravel



    Yii



    Async PHP


    • reactphp/http 1.0 — Первый стабильный релиз асинхронных HTTP клиента и сервера на базе ReactPHP.

      Все основные компоненты экосистемы ReactPHP теперь официально продакшн-реди и имеют долгосрочную поддержку не менее 2х лет.

    phpstorm PhpStorm



    Материалы для обучения



    Аудио/Видео





    Спасибо за внимание!

    Если вы заметили ошибку или неточность — сообщите, пожалуйста, в личку.
    Вопросы и предложения пишите на почту или в твиттер.

    Больше новостей и комментариев в Telegram-канале PHP Digest.

    Прислать ссылку
    Поиск ссылок по всем дайджестам
    Предыдущий выпуск: PHP-Дайджест № 183

    Similar posts

    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 19

      +4
      Спасибо за подборку!
        0
        Вот это разогнались прямо перед фиче-фризом, RFC-пад какой-то.)
        Чего только не предлагают, абы generics не пилить)
        Но в целом весь тот «сахар» лишним не будет, лишь бы производительность не просела и обратной не совместимости не было большой, никто ж не заставляет юзать / переписывать код под восьмёрку.
          0

          Через какое-то время какой-нибудь аудит может заставить.

          +9
          В 8-ке столько изменений, что особого смысла изменения в 7-ке уже нет запоминать:)

          А вот по этому поводу
          One thing that particularly annoys me about naming is this silly `-able` suffix trend for interface names. Let's stop it.
          ️ JsonSerializable -> CastsToJson
          ️Identifiable -> HasIdentity
          ️ Taggable -> ProvidesTags
          ️ Emailable -> EmailMessage

          Не поняли в чем его проблема с able. Diversity что-ли очень нужно и тут?
          Сейчас надо запомнить основу (tag, email, identify) и один суффикс на всех. Вместо этого предлагается запоминать вместо одного able целую кучу допов — provided, has, message, при этом суть не меняется…
            +2

            able vs Has = has более понятный и точный как правило. able — это всё таки возможность, то есть User implements Identifiable можно понять как "у пользователя может быть идентичность (калька)", User implements HasIdentity только как "у пользователя есть идентичность". Естественно подразумевается ситуация, когда в интерфейсе тип результата getIdentity описан как : Inentity, а не : ?Inentity

              0
              согласен, высосанная из пальца проблема… одному не понравилось, т.к. в его мире всё по другому… и некоторые пытаются форсить эту идею…
              0
              Будет ENUM, наконец то! Только вот уже страшно, опыт реализации прошлых фич шепчет что опять какую то дичь придумают «чтобы не как в C/JAVA» =) Посмотрим…
                +2

                Опыт каких фич, например?

                  0
                  Например, атрибутов. Я очень люблю PHP и очень приветствую большинство нововведений, но синтаксис атрибутов просто-таки отвратителен. Посмотрим, что предложат в качестве short syntax.
                    +4

                    А куда вы предлагаете "смотреть"? Все RFC по атрибутам уже приняты, включая короткий синтаксис и больше ничего принимать не предполагается.

                      +2

                      А я, кстати, забежал вперёд.


                      Есть шанс, что пойдут на попятную: https://externals.io/message/111101

                        0
                        Ну хоть что-то. Потому что вот эти << и >> прямо-таки ужас-ужас.
                          +1

                          Ужас-ужас, это принятый "@@". По сравнению с ним << и >> выглядят как эталоны красоты.

                    0
                    Например аннотации. Да, я читал что такому решению предшетвовали исследования и это лучший из имеющихся вариантов, но как говориться «серцу не прикажеш» =). Есть и другие мелочи, например "??=" вместо ожидаемого мной "?=" (не знаю есть ли такое вообще в других языках, просто почему то думал что так будет логично на ряду с "+=" и другими).
                      +1

                      ??= — это объединение ?? и =


                      ?? используется, например, в С#, JavaScript, Swift
                      https://en.wikipedia.org/wiki/Null_coalescing_operator


                      То что вам может не нравиться синтаксис — это понятно и нормально. Вопросы к "опыт реализации прошлых фич шепчет что опять какую то дичь придумают «чтобы не как в C/JAVA» =".

                    +1
                    чтобы не как в C/JAVA
                    Обычно так делают учитывая ошибки

                    В Котлине например так делали крутые фичи… и да, некоторые у них не взлетели так, как задумывал, но все же это движение вперед

                    С енамом то че ошибаться? :)
                      +2

                      Ну да, ведь дело обычно не в отличающемся синтаксисе, проблемах с парсингом и обратной совместимости, а именно «чтобы не как в C/JAVA»

                      0

                      Забавный факт


                      А также подробный ответ Никиты в Internals.

                      А ссылка ведёт на


                      https://externals.io/message/110004#110018

                      Очень PHP-шно :)

                        +1
                        В PHP 8 с именованными аргументами:


                        Именно в этом примере ярко демонстрируется проблема: в названии поля meail сделана опечатка и чтобы это исправить вам придется так же сделать релевантную правку в вашем API (точней она была уже сделана, если этот код работает), который в предыдущем примере был абсолютно независимым.

                        Но скрестив два этих RFC вместе получаем двойную проблему — мало того что имена параметров — теперь часть API, так еще и при неудачном использовании даже приватные поля класса становятся частью API, т.к. описываются через именованные параметры.

                        Я не то чтобы против этих нововведений, но пример, на мой взгляд, совсем не демонстрирует их преимущества, а даже наоборот — выставляет в негативном свете.

                        Only users with full accounts can post comments. Log in, please.