PHP-Дайджест № 122 (11 – 25 декабря 2017)


    Свежая и последняя в этом году подборка со ссылками на новости и материалы. В выпуске: пара свежих предложений из PHP Internals, полезные инструменты, материалы по фреймворкам и асинхронному PHP и другое.

    С наступающим Новым годом! Приятного чтения.


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



    PHP Internals


    • RFC: Scalar Pseudo-type — Предлагается добавить псевдотип scalar для тайпхинтинга любых скалярных значений:
      function f(scalar $param) {
          echo "{$param}\n";
      }
      
    • RFC: Namespace-scoped declares — Предлагается сделать возможным установку директив интерпретатора для целых пространств имен, а не только для каждого файла. Такая возможность позволит добавлять и гибко использовать другие директивы, контролирующие поведение интерпретатора:
      // bootstrap.php
      namespace_declare('Vendor\Lib', [
          'strict_types' => 1,
          ...
      ]);
      


    Инструменты


    • atk4/data — ORM, в которой реализована оригинальная модификация паттерна Data Mapper. Подробнее о том, что не так с другими ORM, и чем хороша эта в посте автора.
    • myclabs/DeepCopy — Позволяет создавать глубокие копии объектов.
    • mikeerickson/phpunit-pretty-result-printer — Расширение для PHPUnit выводит результаты в красивом сгруппированном виде:


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




    Занимательное



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

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

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

    Zfort Group
    0,00
    Компания
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

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

      +1

      Большое спасибо, всё как всегда очень интересно и познавательно)


      Кто что думает про atk4/data?

        0
        Мотивы автора вполне понятны. Другой вопрос в том насколько возможности этой ORM покрывают реальные кейсы и не проще ли писать SQL.
          +3

          SQL обычно всегда писать проще. СЛожнее поддерживать :)

          +5
          Кто что думает про atk4/data?

          очередной велосипед который очень активно форсится его автором. Это не ORM, это не совсем DBAL (хотя ближе к этому)… очень мутная дока… слишком много фич для одного пакета… Что бы объективно понять что это и кому оно надо — надо слишком много времени разбираться. Может быть кто-то осилит. Лично мне это не нужно.

            +2

            Я попробовал разобраться. Похоже на data provider-ы из Yii + гриды / списки.

            +3
            Спасибо за интерес. Я автор atk4/data. Пока весь материал на английском (русский знаю только разговорно), но если есть интерес, могу написать что то по русски.
            +6
            RFC: Scalar Pseudo-type, — по-моему, это уже лишнее, как и mixed.
              +3

              Scalar да, а вот миксед наше все, для некоторых классов.

                +3
                А чем хуже не добавлять никакую проверку типа в этот метод вместо mixed?
                  +5
                  Консистентность и наглядность — это не «забыли указать тип», а «указали любой тип».

                  Но составные типы (несколько типов через пайп) или монады будут лучше, конечно, если есть возможность их использовать.

                  А вот скалярные да, не могу придумать ненатужный пример их использования.
                    +1
                    Если в функцию может прийти null, 0, 0.0, «0» или false и она всё это приведёт к булевому значению, то это, конечно, гибко, но с кодом выше явно что-то не то.
                      0
                      Ну, например, нужна строка, которая куда-то выводится или записывается в файл, допустим. Числа спокойно в строку конвертнутся и выведутся, как надо. А вместо массива будет «Array».
                        0
                        Числа в строку — ок. Буль в строку — не ок. Для этого кейса правильнее указать «int|float|string» (но я не помню приняли ли это RFC).
                          0
                          Тогда нужно составные типы вводить, или какой-нибудь очередной псевдо-тип, или numeric тот же использовать. Видимо, чтобы не париться взяли существующие scalar, а на бул забили.

                          Хотя bool корректно конвертируется в строку и обратно, как и остальные скаляры, в отличии от массивов и остального.
                            0
                            Я о том и говорю — нужные составные типы, потому что они покрывают больше кейсов, чем scalar. И такой RFC уже был, но я не помню его судьбу.

                            Если примут scalar, но не примут составные типы — это будет очень странно.

                            В дополнение к составным типам ещё хорошо бы зашли алиасы для них — можно спокойно будет объявить свой scalar там, где он нужен и ещё много чего.
                              +1
                              Сколько вы хотите от бедного PHP. Потом вам ещё подавай описание схемы ассоциативного массива :)
                      +1
                      Я уже давно привожу в пример реестр, на данный ответ. В реестре может хранится как bool, так и string, так и array (при получении всей ветки). И что я должен выводить, кроме mixed?
                        +1
                        Ничего, просто не делать проверку типов. Вы же таким образом никак не ограничиваете тип, который придет в метод.
                          0
                          Это уже похоже на какой-то «культ карго» и проверки ради проверок. Зачем указывать любой тип в сигнатуре функции в языке с динамической типизацией?
                            +6
                            Не для того, чтобы его язык проверил, а для того, чтобы код был читаемым. Я выше уже привёл пример. Это просто часть стайлгайда — если указываем типы, то указываем везде, хотя бы для того, чтобы не возникало вопросов.
                            Тип — это документация. Если указан mixed, то сразу понятно что ожидать. А если ничего не указано, то нужно открыть реализацию и всю её прочитать, чтобы убедиться что да, mixed, а не просто кто-то забыл тип проставить. Можно, конечно, завести правило «не указан тип читай mixed», но зачем эта когнитивная нагрузка?
                              +1
                              Спасибо за подробное объяснение, звучит разумно.
                              +1
                              Ну да, по сути культ карго. Ровно в той-же степени как и ООП. Мне стало удобней использовать строгую типизацию и «бить разрабов по рукам» за то что они не понимают что к ним приходит и что от них требуется. На данный момент mixed тип висит аккурат пустым, я согласен, это удобно, но если мы говорим про попытку внести строгую типизацию — таких лазеек оставлять нельзя.
                                0
                                Понял, спасибо.
                        +5
                        Я бы в место mixed предпочел иметь возможность перечислять несколько возможных возвращаемых типов, было бы и «строже» и читабельнее.
                          +5
                          Согласен с вами на все сто. Не знаю что останавливает разработчиков php просто взять и скопировать бест практис PHPDoc, где уже давно есть param string|bool. Вот самая ожидаемая фишка была-б.
                          Надо предложить сию идею товарищу Попову, мб заинтересует.
                          +1

                          С другой стороны, есть ситуации, когда прийти может реально любой тип и функция/метод готовы его обработать, например, dump() serialize() и т. п.

                          +3

                          лучше б uniont/interseption типы запилили...

                            0
                            Вот мне тоже кажется, что от этого было бы больше пользы, чем от mixed/scalar. Вроде и разумные способы применения выше в комментариях были описаны, но все равно это какой-то костыль. uniont/interseption те же проблемы решили бы красивее и строже.
                              +4

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


                              type Friends = iterable & Collection

                              Даже без union types и т.п. это уже позволяло бы повысить выразительность и не создавать так много контейнеров для данных, так же это бы горманично сочиталось бы с дженериками (которые хочет МорисонЛеви протолкнуть)

                                0
                                Да, это было бы весьма полезно.
                                +3

                                К слову очень порадовал комментарий SaraMG (релиз менеджер php 7.2) на reddit.

                            +1

                            По поводу amphp/parallel — оно реально раскидает по ядрам или будет на одном ядре делать?

                              0
                              Судя по описанию, по ядрам не раскидает, так как использует Amp. Amp, насколько вижу, реализует корутины с помощью генераторов, что зачастую позволяет значительно поднять производительность даже на одном ядре.
                                0
                                На винде пример из статьи раскидал на 3 воркера (отдельные 3 процесса) и 1 мастер. Возможно, если запустить к примеру на дебиане с каким-нибудь pthreads под php раскидает на потоки, к сожалению сложно проверить.
                                  +1

                                  Раскидает. Но это всего лишь обертка proc_open на yield-ах.
                                  На каждый ParallelTask будет создаваться отдельный php процесс

                                    0
                                    У amphp/parallel есть несколько драйверов для работы. Есть реализация на процессах и тредах. Для тредов нужен pthreads. Для процессов ничего не нужно.
                                  +1
                                  Спасибо за подборку.

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

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