Объявление свойств в конструкторе [перевод]

Larry Garfield пишет отличную серию статей о том, что из себя представляет PHP 8: о скорости, атрибутах, свойствах в конструкторе и многом другом. Сегодня посмотрим на его статью о объявляемых в конструкторе свойствах.

https://platform.sh/blog/2020/php-80-feature-focus-constructor-property-promotion/

Возможно, наиболее существенное улучшение PHP 8, в плане удобства разработки, это объявление свойств в конструкторе. Синтаксис в основном заимствован из Hack — PHP-форка от Facebook, но похожий синтаксис используется и в других языках, например TypeScript или Kotlin.

Сразу приведу простой пример. Рассмотрим типичный класс в современном приложении:

class FormRenderer
{
    private ThemeSystem $theme;
    private UserRepository $users;
    private ModuleSystem $modules;

    public function __construct(ThemeSystem $theme, UserRepository $users, ModuleSystem $modules) {
        $this->theme = $theme;
        $this->users = $users;
        $this->modules = $modules;
    }

    public function renderForm(Form $form): string
    {
        // ...
    }
}

Класс имеет 3 зависимости. Название переменной для каждой зависимости повторяется 4 раза: при описании аргумента конструктора, при описании свойства класса, при описании ссылки на свойство внутри конструктора и при инициализации этой ссылки. Получается очень громоздко, и хотя большинство IDE решают такие задачи авто-подстановкой, это всё ещё боль. Я знаю, что многие люди избегают инъекцию зависимостей из-за громоздкого описания.

В PHP 8 вышеописанную запись сократили до:

<?php

class FormRenderer
{
    public function __construct(
        private ThemeSystem $theme, 
        private UserRepository $users, 
        private ModuleSystem $modules,
    ) { }

    public function renderForm(Form $form): string
    {
        // ...
    }
}

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

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

<?php

class FormRenderer
{
    private User $currentUser;

    public function __construct(
        private ThemeSystem $theme, 
        private UserRepository $users, 
        private ModuleSystem $modules,
    ) { 
        $this->currentUser = $this->users->getActiveUser();
    }

    public function renderForm(Form $form): string
    {
        // ...
    }
}

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

Объявление свойств в конструкторе удобно использовать для простых объектов. Простые объекты — это объекты с некоторым количеством свойств и геттеров/сеттеров для этих свойств. Для таких объектов весь класс можно свести к конструктору:

<?php

Class MailMessage
{
    public function __construct(
        public string $to,
        public string $subject,
        public string $from,
        public string $body,
        public array $cc,
        public array $bcc,
        public string $attachmentPath,
    ) {}
}

Для внутреннего (не являющегося частью API) объекта public-свойства вполне могут использоваться. Если же объект является частью API или взаимодействует с какой-либо внешней системой, то свойства нужно инкапсулировать, и добавить методы для работы с ними. В любом случае код станет компактнее и удобнее.

При объявлении свойств в конструкторе нужно учитывать несколько моментов:

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

Спасибо Никите Попову за этот RFC, хотя поводом послужила моя запись в начале года в этом блоге, так что я требую себе 0.1% 🙂

Мы уже в плотную подошли к релизу PHP 8 и вот-вот сможем увидеть на практике что из себя представляет объявление свойств в конструкторе.

Поиск по триграммам

Этим материалом я открываю серию статей по методам полнотекстовых поисков. Будем разбирать:

  1. Elasticsearch — один из самых востребованных, судя по вакансиям, инструмент. Многое умеет, быстро ищет, поставляется со своим личным стеком утилит. Будем разбираться в следующей статье.
  2. Sphinx. Да-да, он вроде как уже мёртв, а вроде много где используется, хорошо работает, имеет адаптеры под разные языки и фреймворки. Так что — имеет право быть.
  3. Поиск по триграммам — интересный поиск, наименее затратный в плане реализации, и весьма эффективный. Работает благодаря расширению, подключаемому в Postgres. Именно он и будет темой сегодняшней статьи.

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

Читать далее →

Golang: Почему быстрее php и nodejs?

В 2020 у меня стоит цель — если не свичнуться в разработку на го в плане работы, то хотя бы сделать этот язык одним из основных в своём стеке.

Сейчас прохожу курс по go. Разбираясь в теме первых нескольких лекций, решил набросать конспект, сравнить логику работы Go с логикой работы PHP и nodejs, прежде всего затем, чтобы самому запомнить эту информацию. Может быть кому-нибудь это будет полезным 🙂 В ближайшее время изредка будут выходить небольшие, вроде этой, заметки с тем, что мне показалось неочевидным или интересным.

Читать далее →

Паттерн Transactional outbox

Что может быть сложного в логировании? Создал инстанс какого-нибудь Monolog’а, навтыкал $logger->info() под каждой строчкой, выполнение которой хотелось бы запечатлить в истории, и сиди себе посматривай в журнал. А вдруг где-то будет ошибка, лог не сохранится, а логируем мы данные банковских операций?

Я не нашёл информации об этом паттерне на русском (хотя, насколько я слышал, в некоторых книгах его описывают), поэтому думаю, что эта статья имеет право на жизнь.

Читать далее →

Lumen + Docker + Websockets

Image for post

Последнее время работаю с Lumen. Lumen — это урезанная версия Laravel, аля symfony-skeleton для Symfony. По этой причине большинство решений, описанных для Laravel-систем, к Lumen’у прикрутить бывает сложно, а что-то и совсем невозможно, без переопределения vendor-пакетов.

Сегодня расскажу, как и с помощью чьей матери мне удалось завести web-сокеты в Lumen и успешно интегрировать их с Vue-клиентом.

Читать далее →

PHP + Go = ♥ или RoadRunner в действии

Привет.

Много раз уже слышал о RoadRunner — сервер веб-приложений, написанный на Go. Думаю, настало время пощупать, что это такое.

Проблема

PHP работает по простому принципу — один запрос — один процесс. Мы открываем страницу — на сервер уходит запрос. Где-то на сервере есть стек с горячими PHP-FPM процессами, один из которых выделяется и обрабатывает пришедший запрос. Отдав ответ — процесс выгружает все данные из памяти, очищает своё состояние и умирает. Это, я думаю, одна из вещей, почему многие не любят PHP. И правда, при растущих нагрузках рост процессов — неприятный удар по производительности, часто требующий пересмотра архитектуры, масштабирования и редкий поглядываний в сторону потоков, когда разработчик внезапно узнаёт, что они есть в PHP.

Читать далее →

Коротко об mt19937, uniform_real_distribution и генерации одномерных шумных текстур

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

Решение известно давно, но мало где описывается, поэтому продублирую сюда с некоторыми пояснениями, на поиск которых я потратил некоторое время.

  1. Первым делом объявляем класс, который с помощью внешнего источника генерирует начальные данные для последующего их использования в генераторе:

Читать далее →

Заметки. Решение ошибки QOpenGLFunctions_4_1_core: no such file or directory

Что произошло

Появилась ошибка

QOpenGLFunctions_4_1_core: no such file or directory

при попытке сборки проекта клонированного с git посредством qmake и make. В системе стоял как QT4, так и QT5.

В чём была проблема

Класс QOpenGLFunctions_4_1_core появился, согласно документации, в QT5, а qmake подтягивал для сборки инклюды от QT4.

Решение

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

$ qmake --version
QMake version 2.01a
Using Qt version 4.8.7 in /usr/lib/x86_64-linux-gnu

$ qmake -qt=qt5 --version
QMake version 3.0
Using Qt version 5.5.1 in /usr/lib/x86_64-linux-gnu

$ QT_SELECT=qt5 qmake --version
QMake version 3.0
Using Qt version 5.5.1 in /usr/lib/x86_64-linux-gnu

За решение спасибо unix.stackexchange.com && pevik