company_banner

Новое в PHP 7.4

    Новая версия PHP хоть и является минорной, но уже несёт множество новых, без преувеличения, крутых возможностей как для синтаксиса языка, так и для его производительности. Список новшеств не окончательный, но основные изменения уже внесены и приняты. Релиз планируется на декабрь 2019 года.
     

     
    Ключевые изменения грядущей версии:

    • Типизированные свойства классов
    • Предзагрузка для улучшения производительности
    • Стрелочные функции для короткой записи анонимных функций
    • Присваивающий оператор объединения с null (??=)
    • Ковариантность/контравариантность в сигнатурах унаследованных методов
    • Интерфейс внешних функций, открывающий новые возможности для разработки расширений на PHP
    • Оператор распаковки в массивах

    Подробнее об этих и других изменениях читайте под катом.

    Disclaimer: Уже несколько раз в моих обсуждениях с коллегами фигурировала статья Брента «New in PHP 7.4». Сначала я хотел сделать перевод, но в процессе понял, что в тексте указаны не все последние обновления и присутствуют некоторые неточности, поэтому вместо перевода появилась эта статья.

    Стрелочные функции (RFC)


    Стрелочные функции позволяют делать более короткую запись анонимных функций:

    array_map(function (User $user) {
        return $user->id;
    }, $users)
    
    array_map(fn(User $user) => $user->id, $users)
    

    Некоторые особенности принятой реализации стрелочных функций:

    • Они могут получить доступ к parent области, таким образом, нет необходимости использовать ключевое слово use.
    • $this тоже доступна, как и в обычных анонимных функциях.
    • Стрелочные функции могут содержать только одну строку, которая также является оператором возврата значения.

    Подробнее вы можете прочитать о них в этой статье на Хабре.

    Типизированные свойства (RFC)

     
    Ура! Свойства класса теперь смогут иметь type hint. Это очень долгожданное со времён PHP 7 изменение в направлении более строгой типизации языка. Теперь у нас есть все основные возможности для строгой типизации. Для типизации доступны все типы, за исключением  void и callable.

    class Bar
    {
        public string $name;
        public ?int $amount;
        public Foo $foo;
    }
    

    Если хотите чтобы я более подробно рассмотрел новые возможности типизации свойств объектов, отметьтесь в комментариях, и я напишу отдельную статью про них!

    Присваивающий оператор объединения с null (RFC)


    Вместо такой длинной записи:

    $data['date'] = $data['date'] ?? new DateTime();

    Теперь можно будет написать так:

    $data['date'] ??= new DateTime();

    Оператор распаковки в массивах (RFC)


    Теперь можно использовать оператор распаковки в массивах:

    $arrayA = [1, 2, 3];
    $arrayB = [4, 5];
    $result = [0, ...$arrayA, ...$arrayB, 6 ,7];
    <i>// [0, 1, 2, 3, 4, 5, 6, 7]</i>

    Обратите внимание, что это работает только с неассоциативными массивами.

    Интерфейс внешних функций (RFC)


    Интерфейс внешних функций (FFI) позволяет писать код на C непосредственно в PHP-коде. Это означает, что расширения PHP могут быть написаны на чистом PHP.

    Следует отметить, что это сложная тема. Вам всё ещё нужно знание C, чтобы правильно использовать эти возможности.

    Предзагрузка (RFC)


    Предварительная загрузка — потрясающее дополнение к ядру PHP, которое должно привести к некоторым значительным улучшениям производительности.

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

    Повышение производительности происходит «небесплатно» — если предварительно загруженные файлы изменяются, сервер должен быть перезапущен.

    Ковариантность/контравариантность в сигнатурах унаследованных методов (RFC)


    В настоящее время PHP имеет в основном инвариантные типы параметров и инвариантные возвращаемые типы. Данное изменение позволяет изменять тип параметра на один из его супертипов. В свою очередь возвращаемый тип можно заменить на его подтип. Таким образом, данное изменение позволит более строго следовать принципу подстановки Барбары Лисков.

    Пример использования ковариантного возвращаемого типа:

    interface Factory {
        function make(): object;
    }
    class UserFactory implements Factory {
        function make(): User;
    }
    

    и контравариантного аргумента:

    interface Concatable {
        function concat(Iterator $input);
    }
    class Collection implements Concatable {
        function concat(iterable $input) {/* . . . */}
    }
    

    Пользовательская сериализация объектов (RFC)


    Становятся доступными два новых магических метода: __serialize и __unserialize. Данный механизм сериализации объединяет универсальность интерфейса Serializable с подходом реализации __sleep/__wakeup методов. Более подробно с их различиями можно ознакомиться в RFC.

    Приоритет операций при конкатенации (RFC)


    Если бы вы написали что-нибудь подобное:

    echo "sum: " . $a + $b;

    Сейчас PHP интерпретировал бы это как:

    echo ("sum: " . $a) + $b;

    PHP 8 будет интерпретировать это иначе:

    echo "sum :" . ($a + $b);

    PHP 7.4 добавляет предупреждение об устаревании при обнаружении выражения, содержащего "." перед "+ " или "-" и неокружённого при этом скобками.

    Поддержка исключений в __toString (RFC)


    Ранее исключения не могли быть выброшены из магического метода  __toString. Обоснованием этого поведения является то, что преобразования объектов к строкам выполняются во многих функциях стандартной библиотеки, и не все они готовы «правильно» обрабатывать исключения. В рамках этого RFC был выполнен всесторонний аудит строковых преобразований в кодовой базе, и данное ограничение теперь можно снять, что и было сделано.

    Рефлексия для ссылок (RFC)


    Библиотеки, такие как symfony/var-dumper, для точного вывода переменных сильно полагаются на ReflectionAPI. Раньше не было надлежащей поддержки рефлексии ссылок, что заставляло эти библиотеки полагаться на хаки для обнаружения ссылок. PHP 7.4 добавляет класс ReflectionReference, который решает эту проблему.

    Добавлен метод mb_str_split (RFC)


    Эта функция обеспечивает ту же функциональность, что и str_split, но для строк, записанных в многобайтовых кодировках.

    Всегда доступное расширение ext-hash (RFC)


    Это расширение теперь постоянно доступно во всех установках PHP.

    PEAR не включен по умолчанию (EXTERNALS)


    PEAR больше не поддерживается активно, core-команда решила удалить его из установки по умолчанию с PHP 7.4.

    Реестр алгоритмов хэширования паролей (RFC)


    Добавлена новая функция password_algos, которая возвращает список всех зарегистрированных алгоритмов хеширования паролей.

    Слабые ссылки (RFC)


    Слабые ссылки позволяют сохранить ссылку на объект, которая не препятствует уничтожению этого объекта. Например, они полезны для реализации кэш-подобных структур.

    Разделитель числовых литералов (RFC)


    Отсутствие визуальных разделителей в группах цифр увеличивало время чтения и отладки кода, и могло привести к непреднамеренным ошибкам. Теперь добавлена поддержка символа подчёркивания в числовых литералах для визуального разделения групп цифр.

    1_000_000_000  // int
    6.674_083e-11; // float
    299_792_458;   // decimal
    0xCAFE_F00D;   // hexadecimal
    0b0101_1111;   // binary
    0137_041;      // octal
    

    Короткие открывающие теги объявлены устаревшими (RFC)


    Короткий открывающий тег <? устарел и будет удалён в PHP 8. Короткий тег <?= (echo) не пострадал.

    Левоассоциативный тернарный оператор объявлен устаревшим (RFC)


    Тернарный оператор имеет некоторые странные причуды в PHP. Этот RFC объявляет устаревшими вложенные тернарные операторы.

    1 ? 2 : 3 ? 4 : 5;   // deprecated
    (1 ? 2 : 3) ? 4 : 5; // ok
    

    В PHP 8 такая запись приведёт к ошибке уровня компиляции.

    Обратно несовместимые изменения (UPGRADING)


    Вот некоторые из самых важных на данный момент обратно несовместимых изменений:

    • Вызов parent:: в классе не имеющем родителя объявлен устаревшим.
    • Вызов var_dump на экземпляре DateTime или DateTimeImmutable больше не делает доступными свойства объекта.
    • openssl_random_pseudo_bytes выдаст исключение в ошибочных ситуациях, вызванных библиотекой OpenSSL. Раньше она возвращала false, что могло привести к генерации пустой строки.
    • Попытка сериализировать PDO или экземпляр PDOStatement генерирует Exception вместо PDOException.
    • Вызов get_object_vars() на экземпляре ArrayObject возвратит свойства самого ArrayObject, а не значения обёрнутого массива. Чтобы как раньше получить значения обернутого массива — приведите ArrayObject к типу array.
    FunCorp
    218,98
    Разработка развлекательных сервисов
    Поделиться публикацией

    Похожие публикации

    Комментарии 90

    • НЛО прилетело и опубликовало эту надпись здесь
        +2
        Там вроде статически линкуются so-шки (dll-ки). Из сорцов нужны только хедеры, чтобы FFI знал сигнатуры методов и смог автоматом их забиндить. То бишь сишные либы должны быть компилированные под нужную архитектуру заранее.
          +4
          Код заданный через FFI::cdef будет компилироваться условно каждый раз (но не забываем про оптимизации php). Так же есть возможность подгрузить код из C-header файла через FFI::load, но т.к. это занимает значительное время в RFC рекомендуется делать это 1 раз на старте приложения, а работу с FFI оформить через lazy load синглтон дающий доступ к FFI с заданным scope, при этом заранее скомпилировать opcache для него. Пример для второго подхода есть в секции RFC «A Complete PHP/FFI/preloading example».
            +16

            Если раньше в ногу стреляли, то теперь подвезли гранаты. :D

              0
              Да ладно вам, FFI много где есть. И в ПХП он появляется далеко не в первый раз.
            0
            Насчет интерфейса внешних функций например на C я не понял этот код будет налету компилироваться всякий раз или только при первом запуске или еще как?

            Зависит от настроек в php.ini. По умолчанию FFI доступен только в файлах, которые загружаются с помощью preload функционала (файлы для которого, напоминаю, тоже указываются в ini конфигах).


            Пруфы:
            1) ffi https://github.com/php/php-src/blob/master/php.ini-production#L1892
            2) preload https://github.com/php/php-src/blob/master/php.ini-production#L1854


            UPD: Персональное ИМХО по этому всему: Функционал с прелоадом и ffi будет очень слабо востребован в связи с тем, что его почти невозможно нормально использовать.

              +5
              Почему вы думаете что прелоад будет слабо востребован? Что касается FFI то это инструмент, как мне видится, скорее для разработки библиотек нового уровня, там где требуются большие\сложные математические операции и т.д., то есть для машинного обучения и прочего.
                +1

                Потому что он настраивается на уровне php.ini и как следствие — глобален на все проекты на сервере сразу (давайте временно забудем про докер и прочие штуки и возьмём в качестве примера типичный VPS прод или шаред).


                Так что либо придётся прописывать opcache.preload=/home/username/site.org/vendor/preload.php
                под один единственный проект. И при появлении site-2.org уже ничего с этим не сделать.


                Либо делать тоже самое на уровне fpm конфигов в виде php_flag[opcache.preload]=xxx. Что примерно тоже самое, но получше, т.к. можно отдельно воркеры под каждый ресурс запилить.

                  +4
                  Ой как не хочется в текущем веку забывать про контейнеризацию. На VPS то ее кстати тоже вполне можно сделать. А про shared хостинги, придется извращаться, вы правы.
                    +2

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

                      0

                      Так докер — это как раз способ один раз настроить интерпретатор, зафиксировать базовый образ и дальше все проекты наследовать FROM этого образа.

                        0
                        Много ли у вас highload-проектов на докере? Просто интересно.
                          0

                          У меня сейчас уже третий)

                            0
                            Можете назвать их?
                            Какой стек используете?
                            Как доставляете?
                              0

                              В целом я бы не хотел заниматься неймдроппингом, если меня погуглить — всё найдёте. Сейчас я работаю вместе с автором статьи, это видно в хабра-профиле. Стек у нас — монолит на PHP с вынесенным в Java/Kotlin-сервисы performance critical функционалом, БД — Монго, KV — Redis, немного машинки на Питоне, куда без неё. Находимся в процессе переезда из AWS в свой ДЦ, о чём однажды выйдет супер увлекательная статья) Доставляем контейнерами (звучит почти как работа в логистической компании).

            +3
            Отличный набор нововведений. Порадовал «Оператор распаковки в массивах»
              +9
              … писать код на C непосредственно в PHP-коде…
              а в C делать ассемблерные вставки!
                +4
                Справедливости ради, там только декларации на С, что является довольно узким подмножеством языка)
                +2
                Придется чутка пошаманить в шаблонах.
                <?php foreach($somedataarray as $key=>$var):?>
                Some HTML HERE
                <?endforeach?>
                

                Читается имхо хуже, чем <? foreach(): ?>
                  +1
                  Дело привычки, мне сейчас кажется что эти 3 символа не решают.
                  Да и тем более, foreach в шаблоне это не такая частая вещь, обычно это что-то вроде
                  $view->renderPartial('element.template', $dataArray);  
                  

                  Для всяких списков, таблиц, и т.д.
                    –1
                    Тут вполне прокатит <?=
                    Я именно про циклы в шаблонах. Их довольно много обычно.
                    +5
                    Ох как битриксоиды будут рады
                      0

                      На Битриксе 7.2 это уже достижение и пара костылей с порога. Мне даже интересно что будет с php8

                        0
                        А что за костыли если не секрет?
                          –1
                          Да там велосипеды из костылей обычно
                            +2

                            Mb и msqli подключаются отдельными загружаймыми пакетами.

                              –2
                              В 2019 году кто-то все еще пользуется php_mysqli? О_о
                                –1

                                Битрикс, как было сказано ранее.

                                  +3
                                  А в чем проблема с mysqli?
                                    –3
                                    Морально устарел
                                      +2
                                      Это не правда. Mysqli — актуальный драйвер для MySql наряду с PDO (Там есть ряд функциональности, недоступной в PDO для MySql). Устаревший драйвер называется Mysql и его нужно ставить отдельно из PECL, т.к. он удален из стандартной поставки PHP.
                                        –4
                                        php_mysql устарел фактически.
                                        php_mysqli морально.

                                        Подскажите какой именно функционал недоступен в PDO, но доступен в php_mysqli?

                                        Минусят по ходу битриксоиды, которые так и не смогли разобраться с ООП.
                                          +3
                                          Подскажите какой именно функционал недоступен в PDO, но доступен в php_mysqli?

                                          Асинхронные и неблокирующие запросы

                                            +2

                                            Я не знаю нюансов, но мне кажется странной идея, что единственный "правильный" способ — это универсальная обёртка над всеми RDBMS. У движков баз всегда будут уникальные фичи, которые не впихиваются в наибольший общий делитель, поэтому голый полный API имеет право на существование.

                                              0
                                              Например, асинхронные запросы.

                                              С чего вы решили, что mysqli устарел морально, можно какие-то аргументы на этот счет?
                                                –2
                                                Если вам кровь из носу требуются асинхронные запросы в веб приложении, значит у вас что-то не так в архитектуре приложения.

                                                Давайте сравним
                                                mysqli
                                                + асинхронные запросы

                                                PDO
                                                + гарантированное получение в массив строки из БД без плясок с бубном
                                                + биндинг по значению, а не по ссылке
                                                + именованные плейсхолдеры для биндов
                                                + prepared statements на стороне клиента
                                                +? при использовании кверибилдера позволяет полностью абстрагироваться от привязки к конкретной БД и осуществить переход от MySQL, например, на тот же PortgreSQL

                                                Возможно, я несколько преувеличил масштабы в изначальном комментарии, но я согласен с мнением автора вот этой статьи о том, что PDO стоит использовать как решение по умолчанию, особенно для новичков, а mysqli использовать только в тех случаях, когда это абсолютно необходимо by design.
                                                  0
                                                  Я и не говорил, что нужно использовать направо и налево mysqli. Я сказал, что расширение актуальное, а не устаревшее.

                                                  Ясно дело, что для подавляющего большенства случаев нужно брать по-умолчанию PDO.

                                                  А mysqli нужен для тех, кто сильно завязан именно на MySQL и использует ее особенности, с которыми не умеет работать PDO.
                                                +1
                                                При чем здесь ООП вообще, учитывая, что у mysqli есть объектный интерфейс наряду с процедурным?
                                                  +1
                                                  Подскажите какой именно функционал недоступен в PDO, но доступен в php_mysqli?

                                                  LOAD DATA LOCAL INFILE запросы через PDO не работает
                                                    0
                                                    Это с каких пор?)
                                +1
                                учу РНР с 5.3 версии. с каждой новой версией он развивается, улучшается
                                <? объявили устаревшыми и исключения в __toString — порадовали.
                                  +3
                                  С изменением порядка операций будет адская веселуха. Зря они так.
                                    +1
                                    Надеюсь депрекейтед нотисы помогут эту веселуху сгладить, но получается, это делает версию 7.4 обязательной для миграции, чтобы плавнее смигрировать на последующие версии. А само изменение хорошее, раньше было менее логично как по мне.
                                    +4
                                    Если хотите чтобы я более подробно рассмотрел новые возможности типизации свойств объектов, отметьтесь в комментариях, и я напишу отдельную статью про них!


                                    Отмечаюсь. Было бы интересно.
                                      +3
                                      Зачем удалить короткий "<?"?
                                        +2

                                        Одна из причин это совпадение с синтаксисом xml, где то писали об этом...

                                          0
                                          Я не понимаю в чем проблема просто оставить его выключенным по умолчанию?
                                            +2

                                            Он и так сейчас выключен по умолчанию, уже больше пяти лет как. Но вы же видите ситуацию, выше в комментах люди даже не догадываются почему его удаляют, а на тостере полным-полно вопросов "почему гружу на продакшн и не работает".

                                          –1
                                          Потому что идиоты.
                                          Работает, удобно, красиво. Но им «не нравится». XML делали и раньше, и как то жили с этим.
                                          Не люблю когда за меня решают что использовать, а что нет. Надеюсь что будет какая-то петиция для сохранения этого оператора.
                                            +1

                                            Чтобы меньше было проблем "ваш код у меня не работает", а приводить это "не работает" может к утечке чувствительных данных.

                                            +1

                                            Ковариантность/контравариантность
                                            Что то тут не понятно, можно чуть более расширить пример.
                                            Сначала думал там вместо типа сам объект указывается, но нет

                                              +1

                                              Реализация LSP для типов.

                                              +3
                                              Для типизации доступны все типы, за исключением void и callable.

                                              Грустно, что нельзя будет указать свойству тип callable. Я понимаю, что это сделано, чтобы решить такую неоднозначность:


                                              class Foo {
                                                  public callable bar;
                                                  public function bar() {}
                                                  // ...
                                              }
                                              
                                              (new Foo)->bar(); // Вызовится свойство или метод?

                                              Но это не отменяет необходимость иногда хранить функции в свойствах объекта.


                                              Обратите внимание, что это работает только с неассоциативными массивами.

                                              Не верю. Функция array_merge и оператор + прекрасно работают с ассоциативными массивами. Почему тогда оператор распаковки не может?

                                                +1
                                                Опишите логику поведения распаковки в случае коллизии ключей.
                                                Как на ваш взгляд оно должно работать?
                                                  +1
                                                  Ну вот так себе аргумент между прочим

                                                  Что выведет вот этот код?

                                                  <?php
                                                  $a=[1,2];
                                                  $b=[2,...$a, 1=>3];
                                                  var_dump($b);
                                                  


                                                  Внезапно
                                                  array(3) {
                                                    [0]=>
                                                    int(2)
                                                    [1]=>
                                                    int(3)
                                                    [2]=>
                                                    int(2)
                                                  }

                                                  Смотреть upcoming releases, вывод для бранча php-master


                                                    +1
                                                    А чему вы удивлены? Всё логично.
                                                    Если по простому.
                                                    1.
                                                    $b = [2]; 
                                                    #что эквивалентно 
                                                    $b = [
                                                      0 => 2
                                                    ];
                                                    

                                                    2.
                                                    $b[] = 1;
                                                    $b[] = 2; 
                                                    # что эквивалентно
                                                    $b[1] = 1;
                                                    $b[2] = 2;
                                                    

                                                    3.
                                                    $b[1] = 3;
                                                    


                                                    Итог:
                                                    array(3) {
                                                      [0]=>
                                                      int(2)
                                                      [1]=>
                                                      int(3)
                                                      [2]=>
                                                      int(2)
                                                    }
                                                    


                                                      0
                                                      Я не удивлен, я просто привел пример несостоятельности аргумента про коллизии ключей, в комментарии на который отвечал.
                                                    +2

                                                    Оператор может работать точно также как функция array_merge. В вашем примере будет выбрано то значение, которое стоит правее.


                                                    Коллизия ключей может быть намеренной ситуацией. Например, когда параметры передаются в виде массива, и есть параметры по умолчанию:


                                                    function test(array $options) {
                                                        $options = [
                                                            'color' => 'red',
                                                            'size' => 'big'
                                                            ...$options
                                                        ];
                                                        return $options;
                                                    }
                                                    
                                                    var_dump(test(['color' => 'green', 'mode' => 'demo']));
                                                    /*
                                                    [
                                                        'color' => 'green',
                                                        'size' => 'big',
                                                        'mode' => 'demo'
                                                    ]
                                                    */
                                                      0
                                                      Обратите внимание, что это работает только с неассоциативными массивами.
                                                        0

                                                        Я уже отвечал на это: #comment_20249626

                                                          0

                                                          Да, не внимательно прочитал, сорре. Мне тоже такая логика работы кажется странной

                                                    0
                                                    Грустно, что нельзя будет указать свойству тип callable. Я понимаю, что это сделано, чтобы решить такую неоднозначность
                                                    Немного не так.
                                                    public callable bar = ['ClassTest', 'methodTest'];

                                                    Это callable? Вроде да. В чем подвох? а может это все же array? ))

                                                    Но это не отменяет необходимость иногда хранить функции в свойствах объекта.
                                                    Так вроде никто и не мешает:
                                                    public ?Closure bar = null;
                                                      0

                                                      Указанная вами неоднозначность актуальна для всех остальных мест, где можно указывать тип. Closure — это лишь подтип callable; в большинстве случаев такое решение подойдёт, согласен.

                                                    0

                                                    Не очень что тут имееться ввиду, может кто обьяснить?


                                                    Вызов var_dump на экземпляре DateTime или DateTimeImmutable больше не делает доступными свойства объекта.
                                                      0
                                                      Исправлен вот этот баг bugs.php.net/bug.php?id=49382.

                                                      То есть теперь нет возможности сделать так:
                                                      $dt=new DateTime('1742-05-23 00:00:00'); echo $dt->date;
                                                      Notice: Undefined property: DateTime::$date
                                                      
                                                      $dt=new DateTime('1742-05-23 00:00:00'); var_dump($dt); echo $dt->date;
                                                      DateTime Object ( [date] => 1742-05-23 00:00:00 [timezone_type] => 3 [timezone] => UTC ) 1742-05-23 00:00:00
                                                      
                                                      +1

                                                      Сколько всего интересного))) И ковариантность/контравариантность это супер. Давно не хватало.

                                                        0
                                                        Это что же получается в стрелочной функции нельзя будет написать аналог вот этого JS кода?
                                                        [1,2,3].map(item => {
                                                            const newValue = '№' + item
                                                            return newValue
                                                        })
                                                        
                                                          +1
                                                          array_map(fn($item) => '№' . $item, [1, 2, 3])
                                                            0
                                                            Думаю, подразумелось, что нельзя две строки в теле функции.
                                                              +1
                                                              Именно. Так-то в стрелочной функции можно много строк написать и, получается, их все будет сложно запихнуть в одну строку. Печально, но видимо на то были причины
                                                        –2

                                                        Да они упоролись.


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


                                                        Что идёт дальше — я не понял умора. Зачем-то выпилили <?, хотя это очень даже удобно. Не всегда и не везде нужна генерация XML, а если нужен XML, то недолго ровно в одном месте написать вывод через строчку. Для шаблонов удобно и красиво. Было.


                                                        Менять приоритет операторов — это гениальный ход. Народ-то думал, что синтаксические косяки придётся тащить во имя обратной совместимости, но разрабы PHP были полны решимости. Забавно, что какой-то маргинальный синтаксис с конкатенацией изменили, а повсеместно нужный тернарный оператор запретили. Наверное, в этом есть какой-то скрытый смысл, но выглядит странно.


                                                        Всё остальное выглядит положительно, в общем-то. На фоне предыдущих минорных обновлений вообще достойно.

                                                          +1
                                                          Что идёт дальше — я не понял умора. Зачем-то выпилили <?, хотя это очень даже удобно

                                                          Он не нужен, очевидно и доставляет в разы больше проблем, нежели профита. Да и им пользуются лишь совсем новички. Покажите хоть один пакет в композере, где он используется?


                                                          Для шаблонов удобно и красиво. Было.

                                                          Для шаблонов есть шаблонизаторы.


                                                          Менять приоритет операторов — это гениальный ход. Народ-то думал, что синтаксические косяки придётся тащить во имя обратной совместимости, но разрабы PHP были полны решимости.

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


                                                          а повсеместно нужный тернарный оператор запретили

                                                          Тоже самое что и выше: "Не читал, но осуждаю". Никто не запрещал тернарных операторов. Запретили говнокод в тернарниках.

                                                            0
                                                            Он не нужен, очевидно и доставляет в разы больше проблем, нежели профита. Да и им пользуются лишь совсем новички. Покажите хоть один пакет в композере, где он используется?

                                                            <? не используется в публичных пакетах, потому что он непортируем. А вот в закрытых или личных проектах возможность писать шаблоны красиво — удобна. Чуваки из Битрикса, который каждый раз вспоминают при упоминании этого изменения, явно думали так же. Их код не нужно было запускать в условиях, когда <? недоступен.


                                                            Проблема с XML высосана из пальца: если генератор XML гоняется через PHP, то строчкой <?="<?"?> решаются все проблемы. Да, похапэшным разрабам хочется убрать побольше царского наследия, когда поведение языка зависит от недоступных для изменения опций, и это похвально, но выкидывание <? — мёрвому припарка.


                                                            Для шаблонов есть шаблонизаторы.

                                                            Начерта мне шаблонизаторы, если похапэ сам по себе — отличный шаблонизатор? =) Я понимаю, что на большом сайте с десятками подключенных пакетов и активной поддержкой кода плюс-минус шаблонизатор — это статистическая погрешность, но не всегда хочется тащить в миниатюрный проект (а это ненулевая ниша) лишние внешние зависимости. Это не прихоть, это желание не тратить время ещё и на портирование на новую версию зависимости, когда интерпретатор (компилятор?) обновляешь.


                                                            Тоже самое что и выше: "Не читал, но осуждаю". Никто не запрещал тернарных операторов. Запретили говнокод в тернарниках.

                                                            Спасибо, я уже поржал с анализа ситуации в RFC: в 1000 топовых пакетов нашлось 12 использований тернарных цепочек, из которых 9 — баги, а 3 — вроде как норма. Эпик фейл с левой ассоциативностью тернарного оператора уже не исправить, поэтому запрет — это рациональное решение, но вообще-то поломка обратной совместимости в минорной версии в приличном обществе допустимой не считается (джависты вон дженерики поломали, лишь бы виртуальную машину не обновлять — учитесь, что называется =) ). Тем более, когда это ломает 12 из топовых 1000 пакетов, причём ломает не на уровне "в такой ситуации возникнет баг", а на уровне "вообще не запускается". Я уж молчу про менее популярные пакеты.


                                                            С конкатенацией статистика заметно лучше (5 из 5 в топ 2000 — баги), но ссылка на RFC в статье поломана, и мне было лень искать нормальную, поэтому с первого захода не заценил.

                                                              0
                                                              Начерта мне шаблонизаторы, если похапэ сам по себе — отличный шаблонизатор?

                                                              Ну, скажем так, современные шаблонизаторы — это не только вывод с экранированием. И там нативному PHP до них как до луны.


                                                              Но я допускаю, что возможно из-за того, что вообще не помню когда последний раз писал echo не совсем объективен в этом плане.


                                                              поломка обратной совместимости в минорной версии

                                                              Мы все прекрасно знаем какие у PHP "минорные версии"))) Такой же php 5.2 -> 5.3, например, вообще полностью изменил язык в своё время.


                                                              джависты вон дженерики поломали

                                                              Джависты себе давно язык сломали (пользуясь случаем) =)


                                                              Тем более, когда это ломает 12 из топовых 1000 пакетов, причём ломает не на уровне "в такой ситуации возникнет баг", а на уровне "вообще не запускается"

                                                              Ну вообще это ССЗБ. Смотря на такой код: https://github.com/symfony/messenger/blob/4.1/DependencyInjection/MessengerPass.php#L118 Мне рыдать хочется. Блин, неужели так сложно разрабам скобки расставить было? А ещё пишут что в симфони норм код...


                                                              У меня нет, короче, контраргументов =) Ну убили совместимость, да, но как раз в тех местах за которые надо писателей на костёр отправлять.

                                                                +1

                                                                PHP не придерживается semver. "Минорные" релизы всегда были с потерей BC, а "мажорные" всегда означали полное переписывание внутренностей движка. В теории могут быть "мажорные" релизы без потери BC, и даже без изменения самого языка и либ PHP.

                                                            0

                                                            del (промахнулся веткой)

                                                              +1
                                                              Почему это 7.4 минорная версия?
                                                              Команда давно отошла от классического semver
                                                              7 — «версия» zend engine
                                                              4 — мажорщина с крайне вероятной обратной несовместимостью
                                                              остальное — фичи без нарушения обратной совместимости в пределах мажорщины, фиксы и прочая мелочь
                                                                0
                                                                с крайне вероятной обратной несовместимостью

                                                                При обсуждении изменений собрали статистику. Один только RFC по тернарным операторам ломает до уровня "не запускается" 12 из 1000 самых популярных пакетов. Так что это не "вероятность". =)


                                                                Может, разрабы не хотят уподобляться Хрому?

                                                                  0

                                                                  ну я в общем :) щас ломает сильно, 7.1 и 7.2 не очень

                                                                0
                                                                Барбара Лисков довольно улыбается
                                                                  0

                                                                  Обнаружилась интересная штука с типизированными свойствами


                                                                  If a typed property does not have a default value, no implicit null default value is implied (even if the property is nullable). Instead, the property is considered to be uninitialized. Reads from uninitialized properties will generate a TypeError (unless __get() is defined, see next section).

                                                                  То есть, получается, что у нас меняется привычное поведение


                                                                  class A
                                                                  {
                                                                      /**
                                                                       * @var string|null
                                                                       */
                                                                      public $a;
                                                                  
                                                                      public ?string $b;
                                                                  }
                                                                  $a = new A();
                                                                  var_dump($a->a); // NULL
                                                                  var_dump($a->b); // Fatal error: Uncaught Error: Typed property A::$b must not be accessed before initialization

                                                                  Я что-то не уверен, что это правильно.

                                                                    0

                                                                    Ну, то есть понятно, что код мигрирует на PHP 7.4 по другому.


                                                                    class A
                                                                    {
                                                                        /**
                                                                         * @var string|null
                                                                         */
                                                                        public $a;
                                                                    
                                                                        public ?string $b = null;
                                                                    }

                                                                    Но мне кажется это как-то не так должно быть.

                                                                      +1

                                                                      Вполне нормальное решение, по-моему. Если мы не объявим дефолтное значение не для ?string $b, а для string $b, то null быть не должно в принципе там. А делать алгоритим типа: если тип объявлен и он не нуллабл, то бросать ошибку при попытке чтения неиницализованого значения, а если не объявлен или объявлен, но он нуллбл, то инициализровать null, как-то больше усложнит всё.

                                                                        0

                                                                        Тут согласен. Наверное так и правда правильней, но меня смутило то, что переход на type hinting в свойствах класса будет не так очевиден как хотелось бы. Боюсь многие наступят на эти грабли.

                                                                          0

                                                                          Как по мне. то и без перехода на 7.5 не должно быть кода, который рассчитывает на дефолтный null без его явного задания.

                                                                            0

                                                                            Тут скорее не "рассчитывает на дефолтный null без его явного задания", а "не рассчитывает на Fatal error без его явного задания".


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


                                                                            К примеру, ты можешь не ожидать, что этот шаблон может падать с Fatal error у некоторых пользователей:


                                                                            Возраст пользователя {{ app.user.age }}

                                                                            Или форма после отправки может падать с Fatal error если пользователь заполнил не все поля формы или подменил какие-то поля формы.

                                                                              0

                                                                              Точнее нет. После отправки формы скорей можно схлопотать TypeError, а Fatal error скорей при рендере или валидации формы.

                                                                                0

                                                                                Ну, такие кейсы должны быть обнаружены когда принимается решение затипизировать давно существующее свойство. И, скорее всего для начала это будет nullable с явным null, как раз чтобы избежать подобного.

                                                                                  0

                                                                                  Я об этом и говорю, что необходимость объявления свойства как nullable в явном виде при переходе на PHP 7.4 не очевидна.
                                                                                  Не смотря на то, что я изучал вопрос type hunting свойств класса, я упустил из виду эту особенность. Безусловно это полностью моя вина и невнимательность, но я не вижу, что бы кто либо делал акцент на этой особенности. И в RFC этот нюанс описан вскользь и при беглом осмотре его легко упустить. Отсюда я предполагаю, что с этой проблемой могу столкнуться не только я, а ещё очень многие разработчики которые не слишком внимательно следят за всеми фичами в PHP. Хотя возможно мои домыслы надуманы и ни какой проблемы нет. Время покажет.

                                                                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                    Самое читаемое