08.09.2019 22:58
pronskiy 45 10700 Источник

Свежая подборка со ссылками на новости и материалы. В выпуске: PHP 7.4.0 RC1, Laravel 6, Monolog 2 и другие релизы, Union Types и прочие новости из PHP Internals, порция полезных инструментов, пачка подкастов и многое другое.

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



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


  • PHP 7.4.0 RC1 — Стартовал цикл релиз-кандидатов ветки 7.4. Ожидается всего не менее 6 выпусков для стабилизации.
  • PHP 7.1.32, PHP 7.2.22, PHP 7.3.9 — Релизы с исправлениями критичных ошибок безопасности, всем пользователям рекомендуется обновиться.
  • Monolog 2.0.0 — После 4 лет разработки представлен Monolog 2.0. Требует PHP 7.2, используются тайпхинты где возможно и strict_types. Добавлены новые хэндлеры (SqsHandler, TelegramBotHandler) и другое. Monolog 1.x будет поддерживаться и дальше.

PHP Internals


  • [RFC] Reclassifying engine warnings — Предлагается пересмотреть бросаемые нотисы и ворнинги в движке PHP и поправить классификацию там, где необходимо. Во многих случаях предлагается повысить уровень ошибки: Notice -> Warning, например, при попытке получить свойство у не-объекта, и Warning -> Error exception, например, при попытке использовать скаляр как массив. Ну и «Undefined variable» будет бросать Warning.
  • [RFC] Union Types v2 — Предлагается ввести объединённые типы – это значит, что переменная может принимать один из перечисленных типов. Де-факто объединённые типы давно используются в PHPDoc, но теперь они действительно будут проверяться самим интерпретатором.
    Предлагаемый синтаксис T1|T2|... может быть использованы везде, где типы можно указывать сейчас:
    Скрытый текст
    class Number {
    private int|float $number;

    public function setNumber(int|float $number): void {
        $this->number = $number;
    }

    public function getNumber(): int|float {
        return $this->number;
    }
}

    В качестве эксперимента RFC оформлен в виде пулл-реквеста и любой желающий может прокомментировать или выразить реакцию в виде emoji. Финальное голосование будет проходить так же, как и раньше на wiki.php.net. Судя по сообщению Никиты, первый эксперимент прошёл неплохо и было получено много ценных комментариев от сообщества.
  • error_reporting=E_ALL in PHP 8 — В PHP 8 по умолчанию уровень ошибок будет установлен в E_ALL вместо текущего: E_ALL & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED.

Инструменты



Symfony



Laravel


  • Laravel 6 — На конференции LaraconEU представлено мажорное обновление фреймворка. Это LTS релиз и будет получать обновления безопасности в течение 3 лет. Также теперь релиз следует Semver, а значит версия 7 выйдет уже этой зимой. Более подробно об изменениях на русском, и в видео на Laracasts.
  • facade/ignition — Кроме прочего, в Laravel 6 реализована новая страница ошибок. Она базируется на Whoops, но предоставляет больше информации и даже предлагает исправлять простые ошибки не покидая браузера.
  • beyondcode/laravel-view-xray — Удобно подсветит и подпишет вьюшки на странице.
  • stefanzweifel/laravel-stats 2.0 — Artisan-команда, которая выведет разнообразную статистику кода.
  • video PHP Townhall #68: Behind the Facade — Taylor Otwell в гостях у Matt Trask и Ben Edmunds обсуждают, что нового в Laravel, бизнес-сторону дел, и организацию LaraconUS.

Yii



Async PHP



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



Аудио/Видео



Сообщество


  • Matthew Weier O'Phinney, лидер Zend Framework (Laminas) и один из основателей PHP-FIG, закончил работу в Zend и ищет новое место
  • Автор Xdebug Derick Rethans рассматривает возможность сделать Xdebug 3 платным для коммерческого использования. На что Joe Watkins ответил, что экосистеме нужен бесплатный отладчик и в таком случае он будет вынужден реализовать альтернативное расширение.

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

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

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

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

Комментарии (45)


  1. OnYourLips
    09.09.2019 09:59
    #20600205

    Думаю, что самым обсуждаемым будет Union Types v2.
    Крайне не хотел бы его введения, будет помогать писать некачественный код.


    1. levchick
      09.09.2019 10:53
      #20600417

      <sarcasm_mode>Останется только добавить mixed, который позволит использовать любой тип</sarcasm_mode>


      1. Hett
        09.09.2019 12:42
        #20601001

        А потом и вовсе отказаться от статической типизации. И так по кругу.


    1. psycho-coder
      09.09.2019 11:32
      #20600607

      Согласен. Не вижу смысла его вводить после введения строгой типизации. А вы проголосовали в pull-request?


    1. yaroslavche
      09.09.2019 11:55
      #20600753

      Не согласен. Почему сразу некачественный код? Лично мне нравится предложение Union Types. Бывают ситуации, когда нужно вернуть/передать какой-то тип вместе с другим (например, ?string). Теперь же можно будет добавить и еще каких-то типов, если нужно. Что в этом плохого? Лично я бы не пропагандировал их использовать везде, но это хорошая возможность управление данными. Сходу так сложно придумать пример из жизни, но они точно есть. Еще, к примеру, много встроенных функций языка возвращают комбинированные типы. И с этим прекрасно справляется статический анализатор. Насколько будет проще, когда не нужно будет писать PHPDoc комменты с пояснением, что за тип будет у переменной. PHP уже давно движется к полной строгой типизации, и в этом нет ничего плохого. Некачественный код получается не тогда, когда в языке есть возможность, а тогда, когда эти возможности используют бездумно. И сейчас язык вполне себе помогает писать некачественный код, даже без Union Types.


      1. levchick
        09.09.2019 12:32
        #20600955

        Соглашусь с Вами, что некачественный код можно написать тысяча и одним способом и сейчас. Но вот предложение тоже не поддерживаю. Когда язык обязывает указывать строго один тип (в крайнем случае nullable), вам так или иначе придется преобразование типов выносить либо наверх, либо в другой метод, тем самым упрощая этот конкретный метод, избавляя его от необходимости обрабатывать несколько типов. В других строго-типизированных языках такие проблемы решаются перегрузкой, когда для разного набора аргументов (в том числе других типов) определяется другой одноименный метод, реализующий требуемую логику именно для такого набора. Вычитать такой код будет куда проще, чем когда все в одной куче. И уж если PHP идет в сторону более строгой типизации, то было бы логичнее придерживаться более строгого подхода и в данном случае тоже, и вполне достаточно того, что можно типы не указывать вообще. ИМХО, естественно.


        1. yaroslavche
          09.09.2019 12:45
          #20601019

          levchick согласен по поводу декомпозиции. Но бывают ситуации, когда всё-таки нужно обработать несколько типов. Сейчас это только mixed. Помоему, с Union Types типизация станет намного строже в данных случаях. Я как раз-таки и смогу контролировать типы, а не использовать mixed и внутри метода проверять, а что же там пришло в аргументе.


          1. levchick
            09.09.2019 12:49
            #20601055

            Так может декомпозировать и эти ситуации?:) Моя идея в том, что если язык движется в сторону строгости, то и разработчики должны писать более строгий код и стараться избегать ситуаций, где допустимы несколько типов одного аргумента или возвращаемых значений. Там где "капец как надо" или для легаси останется возможность тип не указывать вообще. А принятие этого предложения фактически легализует возможность юзать несколько типов везде где надо и не надо, что точно не приведет к росту качества php-кода.


      1. yaroslavche
        09.09.2019 12:34
        #20600961

        Как пример (сильно не пинайте, возможно я чёт не правильно понимаю =) ):


        public function decode(array|MyClassInterface $object): string|false
{
    return json_encode($object);
}

        Что мы имеем: я не проверяю, вернёт ли json_encode false, просто говорю в сигнатуре, что может вернуть false, и это уже проблема пользователя функции, а не моя. Если захочет — проверит и выкинет исключение. Так же я явно указываю, что метод примет или массив, или объект какого-то интерфейса. Остальное будет TypeError, и не нужно писать проверок и создавать и выбрасывать свои исключения. Замечательно же, нет?


        1. levchick
          09.09.2019 12:39
          #20600993

          В этом случае нужно в phpDoc описать в каких случаях у вас будет false. Кроме этого, чтобы получить информацию о том, почему же все таки false, пользователю метода нужно будет догадаться вызвать json_last_error, а если вы вдруг решите метод поменять и парсить json как-то по другому? Здесь как раз таки намного разумнее кинуть исключение, если string не может быть возвращен, с описанием собственно почему, а пользователю уже решать, что с этим делать.


          1. yaroslavche
            09.09.2019 12:52
            #20601073

            Хмм… Хорошее замечание, я даже не подумал об этом. Но json_decode чисто для примера. Представьте, что это метод, который принимает или объект или массив для инициализации объекта и возвращает строку или false. Да, наверное, логичнее было бы вернуть ?string.


            1. levchick
              09.09.2019 12:57
              #20601105

              Представьте, что это метод, который принимает или объект или массив для инициализации объекта и возвращает строку или false

              Так проблема то собственно не в json, а в том, что вы должны


              1. Четко документировать в каких случаях может быть false (то есть от phpdoc мы не избавимся)
              2. Предоставить механизм получения детальной информации, что пошло не так

              И это все решается как раз таки механизмом исключений.


              Пример, когда возвращается либо результат, либо false, в принципе очень не удачен. Для того же json_decode в 7.3 ввели опцию JSON_THROW_ON_ERROR, чтобы в случае ошибки не false возвращать, а исключение кидать. И в целом этот подход считается одним из самых не удачных во встроенных функциях php


              1. yaroslavche
                09.09.2019 13:28
                #20601287

                Хорошо, я согласен что return-type не лучший вариант для использования в данном конкретном примере. И честно говоря, я бы на самом деле делал с исключениями, как Вы и говорите, я просто стараюсь отстоять мнение, что Union Types это скорее хорошо, чем плохо. Например, что скажете, если я хочу в метод аргументом передать array|MyClassInterface и ничего более?


                1. jetexe
                  09.09.2019 13:55
                  #20601445
                  +1

                  Я, например, скажу, что это плохой код. Если вам надо обрабатывать массив — делайте метод который принимает массив.


                1. levchick
                  09.09.2019 14:29
                  #20601611

                  Давайте по-рассуждаем, что может быть внутри такого метода и как это можно было бы реализовать по другому


                  Очевидно что, для MyClassInterface и для array логика обработки разная либо нам нужно привести аргументы к одному типу, тогда ваш метод будет выглядеть примерно так


                  public function decode(array|MyClassInterface $item): string
{
    if (is_array($item)) {
        // do some logic for array or cast type to MyClassInterface
        return ...;
    }

    // do some logic for MyClassInterface
    return ...;
}

                  Я бы не назвал это хорошим кодом. В данном методе как минимум два блока кода с разной логикой, которая явно напрашивается быть разбитой на два метода. Кроме того, что если потребуется реализовать decode для какого-нибудь другого типа? Нам придется модифицировать метод и добавлять еще одно условие и т.д.


                  В классических языках со строгой типизацией это бы решилось простой перегрузкой и код превратился бы в что-то типо того


                  public function decode(array $item): string
{
    // do some logic for array or cast type and call decode with MyClassInterface argument
    return ...;
}

public function decode(MyClassInterface $item): string
{
    // do some logic for MyClassInterface
    return ...;
}

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


                  public function decodeArray(array $item): string
{
    // do some logic for array or cast type and call decode with MyClassInterface argument
    return ...;
}

public function decodeMyClass(MyClassInterface $item): string
{
    // do some logic for MyClassInterface
    return ...;
}

                  Таким образом, если нам необходимо будет реализовать decode для чего-то еще нам нужно всего лишь добавить еще один метод (а не модифицировать старый Open/Closed из SOLID) и мы гарантированно не сломаем то, что уже работает.


                  Либо, если array можно представить в виде MyClassInterface, то реализовать MyArrayClass, который бы создавался из массива и имплементировал MyClassInterface, и у нас бы остался decode с одним типом аргумента. Ну и конечно наоборот, когда MyClassInterface можно представить в виде массива…


                  Вот по этому я считаю, что Union Types нужен в большинстве случаев для того, чтобы засахарить тот код, который стоило бы отрефакторить, и фактически легализует написание кода из примеров выше.


                  1. molchanoviv
                    09.09.2019 18:08
                    #20602715

                    Единственный валидный кейс который я вижу это в функции дергающей внешнее апи возвращать SuccessResponse или ErrorResponse в зависимости от того что вернуло апи, но как по мне этого явно недостаточно для введение такой сомнительной фичи.


                    1. levchick
                      09.09.2019 18:34
                      #20602827
                      +1

                      Так пусть возвращаемым типом будет ResponseInterface, а SuccessResponse и ErrorResponse будут его имплементировать. И фич никаких не нужно.


                      1. molchanoviv
                        09.09.2019 19:32
                        #20602995

                        Именно так я и делаю. Я просто привёл более-менее валидный кейс. Сам я тоже против такой фичи.


                  1. yaroslavche
                    11.09.2019 02:58
                    #20608293

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

                    Не совсем согласен. Допустим, у меня массив с параметрами инициализации дефолтного объекта MyClassInterface. Что-то типа такого:


                    public function decode(array|MyClassInterface $item): string
{
    if (is_array($item)) {
        $item = new DefaultItem($item);
    }

    if(!$item instanceof MyClassInterface) {
        throw new InvalidArgumentException('...');
    }
    return $item->decode();
}

                    Это нужно читать так: я предоставляю метод, который является оберткой к decode и может принимать разные типы аргумента. Но не любые. Это должен быть или массив для инициализации объекта, или сам объект. Да, я могу предоставить два метода для decodeArray и для decodeMyClass. А могу один. Соблюдая строгую типизацию.
                    Т.е. я просто привожу типы в одном методе, а реализация по факту одна — MyClassInterface::decode. Так же в Вашем примере всё также нужно проверить, какой тип пришел, что бы вызвать соответствующий метод и нужно так или иначе полагаться на mixed (где-то же Вы должны решить какой из методов decodeArray или decodeMyClass вызвать) и выбрасывать исключение, если это не array или MyClassInterface. В случае с Union Type всё что не array|MyClassInterface будет автоматически TypeError, а в Вашем случае — не факт что разумно названное исключение (если не просто Exception или InvalidArgumentException).
                    По этому мне в коде достаточно проверить, массив ли это, если да — преобразовать, потом на всякий случай проверить преобразовало ли, если был массив (потому что иначе это в любом случае MyClassInterface), а потом вызвать MyClassInterface::decode. Более того, не всякий массив подойдёт и может сфейлится конструктор, к примеру. То, о чем Вы говорите, и как есть сейчас — придется в любом случае проверить тип, и писать свитч? (утрирую, извините =) )


                    А вообще, это можно, видимо, долго спорить =) Кто-то из нас не полностью прав в отношении к Union Types. Возможно я. Возможно Вы. Увидим после голосования =)


                    P.S. решил почитать больше информации. Нашел уже отклоненный v1. Надо изучить подробней, чем они отличаются, а то судьба у первой версии незавидная.


                    1. psycho-coder
                      11.09.2019 11:00
                      #20609347

                      Понимаю, что это пример. Но, что можно делать методом decode() с массивом?


                      1. yaroslavche
                        11.09.2019 11:37
                        #20609569
                        -1

                        тот метод можно назвать как угодно. Пускай это будет doSomething и принимать не массив, а что-то другое. Допустим — string. Не цепляйтесь за слова, пожалуйста.


                        1. psycho-coder
                          11.09.2019 11:43
                          #20609593
                          +1

                          Хорошо, не буду цепляться.
                          Данный пример мне очень сильно напоминает WordPress, с их WP_Post|Int|Null и пачкой проверок внутри. В связи с этим и хочется найти практическое применение UT, а не примеры в вакууме. Сам я пока не могу придумать, где и как такое применять.


                          1. yaroslavche
                            11.09.2019 12:13
                            #20609765

                            Сам я пока не могу придумать, где и как такое применять.

                            Думаю, Вы согласитесь, что это совсем не означает, что кейсов не существует. Как минимум — это отказ от типов в аннотациях (наконец-то). Еще фичи, что мне нравятся: type alias, псевдотипы, нормальный nullable (а не ?), В PR не сравнивают это с WordPress, и видимо, видят кейсы, судя по комментариям.
                            Не знаю. Мне нравятся UT. Если Вам нет — не пользуйтесь, никто же насильно не будет заставлять. Я устал дискутировать, честно говоря. За сим откланяюсь.


          1. michael_vostrikov
            09.09.2019 20:34
            #20603189
            -1

            Здесь как раз таки намного разумнее кинуть исключение, если string не может быть возвращен, с описанием собственно почему, а пользователю уже решать, что с этим делать.

            С Union Types можно это исключение просто вернуть. Его и сейчас можно вернуть, только обрабатывать это неудобно, и контролировать сложнее, надо не использовать типизацию вообще.


        1. arturpanteleev
          09.09.2019 16:29
          #20602241

          Такой метод не должен возвращать false
          Он должен или возвращать строку если все получилось, или кидать исключение, если что то пошло не так.


          1. yaroslavche
            11.09.2019 04:21
            #20608371

            Не должен, но json_encode возвращает. И не только эта функция. В данном конкретном примере я предоставляю метод который возвращает результат работы функции SPL. Допустим там еще много вычислений перед возвратом. Конечный пользователь может не использовать метод, посчитать сам и использовать json_encode, если ему больше нравится return false оттуда


            1. yaroslavche
              11.09.2019 05:03
              #20608411

              К слову, нам и не нужно возвращать false, т.к. благодаря union types у нас гарантировано (я так думаю) будет строка. И исключений выбрасывать не нужно. В общем, это просто пример.


            1. arturpanteleev
              11.09.2019 10:06
              #20609043
              +1

              с версии 7.3 он уже может кидать исключение при указании JSON_THROW_ON_ERROR
              Ну и в целом стандартная либа php явно не образец для подражания в плане качественого API


              1. yaroslavche
                11.09.2019 11:29
                #20609513
                -1

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


                1. t_kanstantsin
                  11.09.2019 13:29
                  #20610183
                  +1

                  Пример json_encode как раз показывает, что такой подход не многим нравится. Если бы такое поведением было приемлемым, то его бы не меняли.


          1. psycho-coder
            11.09.2019 11:02
            #20609359

            Поддерживаю. Хотя в некоторых ситуациях использую ?Type, чтобы вернуть null.


      1. a_mazur
        09.09.2019 12:42
        #20601003
        +1

        Бывают ситуации, когда нужно вернуть/передать какой-то тип вместе с другим

        Возможно Вы имеете в виду «вернуть несколько аргументов из метода» — так для этого Union Types не нужен — с этим вполне справляется и массив (как минимум):
        return [$val1, $val2];

        В C# для этого завезли кортежи, в Java можно часто встретить что-то типа:
        class Pair<T, U> { ... }

        Что к слову тоже не является примером отличного кода — ведь как так? Вы не знаете какой тип Вы должны вернуть и прибегаете к обобщенному коду?
        (например, ?string)

        Ну так это влияние других ЯП e.g., Java/C#, что к слову не самое топовое решение, почитайте про null pointer hell.
        Еще, к примеру, много встроенных функций языка возвращают комбинированные типы.

        А вот это вообще отдельная песня. SPL уж точно не является примером для подражания. Нашумевшая, хоть уже и несколько устаревшая статья «PHP — fractal of bad design» является отличной иллюстрацией моих слов.
        Насколько будет проще, когда не нужно будет писать PHPDoc комменты с пояснением, что за тип будет у переменной.

        Я возможно скажу что-то новое для Вас, но PHPDoc комменты нужны скорее для того, чтобы понять зачем «интерфейсу» метода нужны те или иные параметры. Типы PHPDoc'a уже не так нужны, если Вы не работаете со старым legacy кодом конечно.
        Некачественный код получается не тогда, когда в языке есть возможность, а тогда, когда эти возможности используют бездумно. И сейчас язык вполне себе помогает писать некачественный код, даже без Union Types.

        Согласен, вот только сама возможность использовать Union Types не будет помагать с решением этой проблемы ничем — только усугублять.


        1. yaroslavche
          09.09.2019 13:08
          #20601173

          Возможно Вы имеете в виду «вернуть несколько аргументов из метода» — так для этого Union Types не нужен

          Нет же. Я как раз о возвращаемом типе значения. Допустим — это или int, или string.


          Что к слову тоже не является примером отличного кода

          Полностью согласен, ведь я говорил не об возврате нескольких значений, а о типе.


          SPL уж точно не является примером для подражания

          Тем не менее, к сожалению, я вынужден ней пользоватся. А там есть функции возвращающие значение, которое может быть разным типом.


          Я возможно скажу что-то новое для Вас, но PHPDoc комменты нужны

          PHPDoc комменты нужны также для автокомплита в IDE, например где то в теле метода я получил обьект, но у метода не было return-type и IDE не знает что это, ну я и пишу:


          public function method():void
{
# some code
/** @var InstanceInterface $object */
$object = SomeOtherClass::get($someObjectName);
# some code

          так же указание типов в PHPDoc важно и для статических анализаторов.


          1. a_mazur
            09.09.2019 16:01
            #20602101
            +1

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

            К сожалению, мы все вынуждены ей пользоваться. Но Вы ведь понимаете, что union types не сделает SPL лучше?
            Как говорили выше — куда лучше выбрасывать ошибку в непонятной ситуации, а не false.
            Ну и как бы там ни было — ни того ни другого скорее всего в SPL не будет, твит на тему.

            PHPDoc комменты нужны также для автокомплита в IDE, например где то в теле метода я получил обьект, но у метода не было return-type и IDE не знает что это, ну я и пишу

            Опять таки, ну и чем Вам здесь поможет union types?

            Как бы то ни было, я просто хочу подрезюмировать свое отношение к данному предложению — строго отрицательное. И вот почему: жизнь это не упростит аж никак (ну хочется прогеру поговнокодить, вернуть несколько различных типов — никто же не заставляет писать m():types), а вот потенциальных неприятных вещей добавит уж точно.


            1. yaroslavche
              11.09.2019 03:59
              #20608355

              union types не сделает SPL лучше

              Понимаю, и не утверждаю, что сделает


              ну и чем Вам здесь поможет union types?

              а тем, что вместо написания union types в PHPDoc я буду писать его в коде, там где мне нужно. И не нужно говорить о том, что это всё надо рефакторить, я это понимаю. Просто у меня уже привычка в PHPDoc писать тип для свойства класса. В 7.3 эта привычка не нужна (хотя я честно говоря еще особо не пользовался 7.3 =)). Так же мне иногда приходится писать union types в PHPDoc для статического анализатора (и не только потому, что мне так хочется). Честно говоря, я был бы не против иметь возможность писать эти типы "легально", а не с помощью аннотаций. По моему это просто самый обычный самодокументирующийся код. Но опять же, я прекрасно понимаю, что могу ошибаться. Ну хочется мне поговнокодить, что поделать. Вам от этого хуже не будет =) Я вообще считаю, что как минимум union types лучше, чем вообще не указывать ничего, если таки нужно вернуть/передать не единственный тип. А такие случаи реальны, их не нужно списывать со счетов, потому что это "говнокод".


    1. i80586
      09.09.2019 12:00
      #20600779

      Согласен. Тем более что вряд ли будет разрешено использовать мульти-объекты: getModel(): Post|Category


      1. yaroslavche
        09.09.2019 12:16
        #20600865

        i80586 думаю, скорее всего будет можно, но я могу ошибаться. В данном конкретном случае, если у Вас больше двух моделей, то лучше использовать какой-то ModelInterface в return-type, ИМХО. Но если именно хотите эти два класса — то ок, почему нет? Вот есть у меня их 3, а я хочу разрешить только 2 для метода. Union types поможет разрешить передачу/возврат только определенных типов данных, и, по факту, отказаться от mixed.


        1. i80586
          10.09.2019 10:46
          #20604629

          Понимаю. Но тогда для IDE будет путаница какой класс использовать в данном случае в качестве подсказчика.


  1. bm13kk
    09.09.2019 11:17
    #20600521

    > [RFC] Object Initializer

    Реализация завязана на публичные методы. Первое (и единственное для меня) место где это нужно — в доктрине — не заработает.

    Могло бы взлететь, если бы в пыхе были бы public final атрибуты — это когда один раз засетил и потом нельзя менять. Тогда можно все dependency полностью убрать из конструктора и сделать публичными. Что в свою очередь сократит очень много бойлерплейта.


    1. eee
      09.09.2019 13:35
      #20601321

      Иммутабельность то бишь?


      1. bm13kk
        09.09.2019 14:47
        #20601715

        Иммутабельность аттрибута.

        Иммутабельность, все таки, это когда ничего в обьекте менять нельзя.

        Хотя полная иммутабельность и этот синтакстис гораздо вкуснее.


  1. michael_vostrikov
    09.09.2019 20:27
    #20603171
    -2

    Union Types

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


    1. michael_vostrikov
      09.09.2019 23:29
      #20603737

      Кто-то не согласен, что раз на передающей стороне (выход функции) появились новые возможности, то надо и на принимающей (место вызова) сделать средства их обработки? Или просто с тем, что это полезно? Раз в других языках делают, то наверно есть какая-то польза от этого.


  1. Maksclub
    09.09.2019 20:41
    #20603223
    +1

    Union Types. Первый шаг к дженерикам? Почему бы сразу их не реализовать?


  1. spasibo_kep
    09.09.2019 22:51
    #20603645

    Привет, еще из, надеюсь, кому-то полезного: мы делаем PHP-митапы в Самаре 28-го сентября и Ульяновске 19-го октября — приходите или приезжайте, если где-то рядом)