PHP-Дайджест № 185 (20 июля – 3 августа 2020)


    Свежая подборка со ссылками на новости и материалы. В выпуске: PHP 8 Alpha 3, PhpStorm 2020.2, новый оператор ?->, снова обсуждение синтаксиса атрибутов и другие новости PHP Internals, обзор системы типов в PHP, порция полезных инструментов, видео, стримы и многое другое.

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



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


    • PHP 8.0.0 Alpha 3 — Последний альфа-релиз из запланированных. Первая бета ожидается 6 августа.
    • Релиз PhpStorm 2020.2 — Объединенные типы PHP 8, новый движок потока управления, пул-реквесты GitHub, OpenAPI. По ссылке подробный разбор этих и других изменений.

    PHP Internals


    • [RFC] Shorter Attribute Syntax Change — История с синтаксисом атрибутов в PHP 8 продолжается. Предыстория была в канале.

      Вкратце: сначала был << >>, переголосовали за @@, а теперь новый виток обсуждений.
      У @@ были проблемы с парсером, но они решены благодаря нижеупомянутому RFC про неймспейсы. Тем не менее у него есть другие проблемы, и в качестве альтернативы предлагался вариант #[ ] как в Rust, но и у него есть минусы.

      Дошло до того, что рассматривается вариант переголосования за новый синтаксис и перенос атрибутов в PHP 8.1, потому что фиче-фриз для 8.0 уже 4 августа. То есть либо в PHP 8.0, но с одним из << >>, #[], @@, либо в PHP 8.1 с чем угодно.

      Для последнего случая предлагаются самые разные новые варианты: @[Attribute], в комментарии PHPDoc с двойной собачкой /** @@MyAttribute */, или даже маловероятный — переделать оператор подавления ошибок из @ в @@, а одинарную @ использовать в атрибутах.



      Еще забавно, что в ответ на письмо Дерика об ужасности @@, кто-то написал, что T_PAAMAYIM_NEKUDOTAYIM тоже ужасен, но не тут-то было — в PHP 8 Alpha 3 он уже не отображается для пользователя.
    • check [RFC] Treat namespaced names as single token — В PHP 8 весь неймспейс считается одним токеном. Это позволяет использовать внутри неймспейса ключевые слова, например, namespace app\function { class Foo {} } и избавляет от потенциальных проблем обратной совместимости при введении новых ключевых слов.

      Надеюсь, вам такое не приходилось встречать, но с этим изменением неймспейсы не могут содержать комментарии:
      use /** Try comments */ \FullyQualified \ /* in this ugly way */ SometTotallyDifferentTrait /** also after */;
    • check [RFC] Saner string to number comparisons — Почти единогласно прошло предложения ломающее обратную совместимость.

      В PHP 8, при сравнении чисел и строк с помощью нестрогого == оба операнда приводятся к строке и сравниваются как строки, если один из них не является числовой строкой.

      0 == 'foobar' теперь официально false.


      Это также влечет за собой изменение поведения всех операторов сравнения <=>, ==, !=, >, >=, < и <=, конструкции switch, функций типа in_array(), sort() и других.
    • check [RFC] Nullsafe operator — В PHP 8 будет новый оператор nullsafe: ?->.
      C ним вместо пачки вложенных условий можно обращаться к свойству или методу с проверкой на null.

      Например, такой приватный метод с кучей условий:
      Скрытый текст
      
      private function getUserCountry(): ?string
      {
          $session = $this->sessionStorage->getSession();
      
          if (null === $session) {
              return null;
          }
      
          $user = $session->getUser();
      
          if (null === $user) {
              return null;
          }
      
          if (null === $user->address) {
              return null;
          }
      
          return $user->address->country;
      }
      
      можно будет заменить одной строкой:
      $country = $this->sessionStorage->getSession()?->getUser()?->address?->country;

      Прислал Валентин Удальцов (@Пых).
    • check [RFC] Allow trailing comma in closure use lists — В конце списка use у замыканий в PHP 8 можно будет оставлять запятую по аналогии с тем, как это уже работает для аргументов и параметров функций.
      Скрытый текст
      
      $f = function (
          $longArgument,
          $longerArgument,
          $muchLongerArgument,
      ) use (
          $longVar1,
          $longerVar2,
          $muchLongerVar3, // Вот тут теперь тоже можно запятую
      ) {
         ...
      };
      
    • check [RFC] Named Arguments — В PHP 8 будут именованные аргументы!
      Теперь можно будет передавать значения в функцию или метод на основе имени параметра, а не только его позиции.
      htmlspecialchars($string, ENT_COMPAT | ENT_HTML401 , ini_get("default_charset"), false);
      станет:
      htmlspecialchars($string, double_encode: false);

      Подробнее об именованных аргументах в посте stitcher.io/blog/php-8-named-arguments.
    • [RFC] Renamed Parameters — Проблема переименования параметров методов была основным камнем преткновения в обсуждении именованных аргументов. Именно ее пытается решить автор этого RFC.

      Предлагается добавить возможность указывать внутреннее и внешнее имя параметра через двоеточие:
      
      function callBar(Foo $internalName:externalName) {
          $internalName->bar();
      }
      
      $x = new Foo();
      callBar(externalName: $x);
      

      Что-то подобное есть в Swift. В качестве альтернативы, возможно решение в виде атрибута @@NameAlias.
    • cross [RFC] Make constructors and destructors return void — Отклонен.

    Инструменты



    Symfony



    Laravel



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



    Аудио/Видео



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

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

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

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

    Similar posts

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

    More

    Comments 22

      +1
      спасибо за подборку!
        0
        Ссылка «MoreView #13» ведёт на «MoreView #12»
          0

          Поправил, спасибо

          +1

          По-моему, статья "Почему плохо надеяться на БД для валидации данных" — это из вредных советов.

            +1

            Почему?

              +6

              1 — NULL/NOT NOT, unique, fk — это все не только бизнес логика, но и технические ограничения. Позволяющие лучше понять, как разработчику, так и СУБД как лучше (правильнее) работать с данными.
              2 — Если у приложения несколько интерфейсов, то и бизнес требования на каждом из них могут отличаться. СУБД тут может выступать арбитром в принятии конечного решения, проходят ли данные или нет.
              3 — Иногда данные таки приходится править через различные db viewer-ы, да или даже миграции, где ты их вносишь в обход валидаций уровня приложения. Те же foreign keys или unique таким образом можно легко нарушить.
              4 — В целом, зачем тогда реляционная СУБД? Все скатывается в NoSQL и контроль данных на уровне приложения.

                0

                РСУБД для джойнов

                  +3
                  1.1 Пример автора статьи, по валидация уникальности, ломается конкурентными запросами, но он об этом узнает не сразу
                  +6

                  Потому что автор слишком уж узко мыслит.


                  Валидность данных не должна зависеть от какого-то там условного ларавеля. Сегодня это только ларавел, завтра к нему добавились дотнет и питон. А послезавтра автор запушил релиз с багом в валидаторе и как наташины котики уронил вообще всё.


                  Уникальные и внешние ключи, NOT NULL и прочее — они не только про валидацию, они ещё и про построение модели данных, которой очень охотно пользуется оптимизатор.


                  Так что я на 100% согласен с предыдущем комментарием — советы очень вредные, особенно для использования в больших системах. Сначала автор не описал в СУБД модель данных, через полгода появилась необходимость создать парочку реплик базы, потому что всё тормозит, через год у вас в штате уже есть табунчик девопсов. Зато DDD и феншуй.1)


                  1) Феншуй в понимании его автором статьи с вредными советами.

                    –1
                    Часть логики вообще в хранимках может быть.
                      +3

                      Может быть, но вот тут как раз соглашусь с автором статьи, что хранимки лучше избегать и использовать только, если по-другому никак.

                    +4

                    Надеяться на БД в вопросе валидации данных действительно плохо, по-моему. Но ограничения уровня БД полезны как последний рубеж защиты от ошибок (или выбранных компромиссов) программиста (не пользователя). Попытки нарушения схемы БД должны отдавать 500 в контексте HTTP, а не 400 за редкими исключениями когда ради нефункциональных требований типа быстродействия приходится идти на возможные ошибки в SQL типа unique constraint violation, чтобы не лочить таблицы на запись.

                    +4
                    [RFC] Saner string to number comparisons

                    Это будет славная охота. Хотя для многих она будет последней. Что скажете? (с) Маугли
                      +1
                      Это будет самым серьезным препятствием для миграции крупных приложений. Особенно если с тестами беда
                        0
                        Правильно я понимаю, что теперь:

                        $a = "9"
                        $a > 100 // true - php 8
                        $a > 100 // false - php 7
                        


                        Это же ломает вообще всё…
                    +3
                    В PHP 8, при сравнении чисел и строк с помощью нестрогого == оба операнда приводятся к строке и сравниваются как строки, если один из них не является числовой строкой.

                    0 == 'foobar' теперь официально false.

                    Теперь собеседующим придётся указывать версию языка в вопросах о нестрогом сравнении =)
                      +1
                      А такой вопрос еще задают на собеседованиях? Вроде нулевые уже давно прошли.
                        0

                        Нет. Теперь собеседующие будут ставить минус, если собеседуемый не спросил "а мы покупаем или продаём какая версия?"

                        +3
                        А мне нравится идея изменить оператор подавления ошибок на @@, а одиночную собаку использовать для аннотация. И пусть это будет хоть в 8.1, хоть в 9. Доктриновские аннотации всем хороши и вводить их в синтаксис языка — не более, чем блаж, без которой спокойно можно обходиться еще пару лет. Так что не стоит торопиться и уродовать и без того не самый лаконичный язык кривым синтаксисом аннотаций.
                          +6

                          Это просто праздник какой-то, особенно про сравнение. Дело даже не в том, что более ожидаемый результат будет, а в том, что ломают BC в одной из "духовных скреп" PHP, что означает, что и другие 'столпы" не так твёрдо стоят. Глядишь и дойдём до строго динамически типизированного интерпретируемого языка

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