Кирилл Несмеянов

При этом я через if ($errors) else как раз и проверяю существование переменной.

if - это не проверка на существование. if - это проверка на то, что существующая переменная соответствует boolean true. Почитайте, пожалуйста документацию по основам языка: php.net/manual/ru/control-structures.if.php

Есть несколько вариантов решения это проблемы.

1) Некоторые могут пропагандировать сервисный слой (design-pattern.ru/patterns/service-layer.html), как следствие: "App/Services/ServiceName" - набор классов, отвечающих за какое-то абстрактное действие. Например: "UserAvatarUploaderService", который отвечает за загрузку аватарки пользователя.

2) В качестве альтернативы и способ, который предпочитаю я - это создание директории "src" с набором независимых компонентов, включая собственный composer.json. Тот же сервис загрузки аватарки будет выглядеть следующим образом:

- src/
    - AvatarUploader/
        - README.md
        - composer.json
        - tests/ ...
        - src/
            - AvatarInterface.php
            - FileSystemInterface.php
            - FileSystemUploader.php
            - UploaderInterface.php

Для подключения этой библиотеки достаточно будет прописать в корневом:

{
    "repositories": [
        {
            "type": "path",
            "url": "./src/AvatarUploader"
        }
    ],
    "require": {
        "app/avatar-uploader": "*"
    }
}

А выглядеть внутренний (т.е. внутри "src/AvatarUploader") composer будет так:

{
    "name": "app/avatar-uploader",
    "autoload": {
        "psr-4": {
            "AvatarUploader\\": "src/"
        }
    }
}

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

function money (int $count = 100500): iterable {
    for ($i = 0; $i < $count; ++$i) {
        yield $i => $count;
    }
}

foreach (money() as $current => $available) {
    echo "\rПожалуйста подождите, идёт загрузка денег $current из $available";
    \flush();
    \usleep(10000);
}

Всё печально. Давай по-порядку:

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

class Worker extends User // <- Не стоит забывать о PSR
{
    public function __construct(array $data)
    {
        if (empty($data)) {
            header(....);
            exit;
        }

        // В конструкторе нет ретурна, так что это ошибка
    }
}

Шаг 1 Результат: Мы отвязались от кукисов и можем эту же логику переиспользовать вообще с чем угодно.

Теперь мы больше не связаны с окружением (ещё header надо убрать) и имеем код, позволяющий переиспользовать себя в различных ситуациях:
$worker = new Worker($_COOKIE);

Ну и так далее.

При этом есть фатальные косяки (отвечая на твой вопрос "Нормально ли так проверять авторизацию"): Что если я возьму, открою консоль в браузере и заменю кукис id=1 на id=42?

Решаем эту проблему:
$worker = new Worker($_SESSION);

Вот и пригодились все "улучшения", которые мы произвели ранее. Для решения проблемы нам понадобилось лишь заменить источник данных (т.е. массив) из кукисов на сессии. Этот процесс передачи данных извне называется "делегированием".

Помимо этого - сам процесс входа в систему называется "аутентификацией", а не "авторизацией". Авторизация - это процесс проверки прав доступа к какому-то функционалу.

Результат не идеален и содержит ещё кучку проблем, но с фатальными мы вроде разобрались.

Твоя задача далее, разу уж ты поставил тег "ООП" - смотреть на код, который ты написал и попробовать его перенести в другие условия. Если он там уже работать не будет без изменений его внутренностей - значит в коде есть набор косяков. Пример:
1) Можно ли использовать твой код, получая данные не из БД, а из файлов?
2) Можно ли создать нового "рабочего" не передавая туда ID, чтобы он сгенерировался сам на основе, например, auto increment поля в БД?
3) Можно ли добавить условия в запрос к БД (например, что "рабочий" не забанен)?
4) и т.д.

В чем недостатки такого решения?

Помимо отсутствия транзакционности в коде (о чём уже упоминали выше):

1) Нет ключа на thread_id (желательно foreign)
2) Типы в INT, вместо UNSIGNED INT
Т.к. это MySQL, судя по вопросу, то:
3) Нет указания на collation таблицы (желательно utf8mb4)
4) Нет указания на движок таблицы (транзакции есть только в InnoDB и их нет в ISAM, MyISAM, Archive, Memory, etc.)
5) Нет уникальности голосов (т.е. votes), как следствие - таблица денормализованная и подсчитывать так голоса - крайне глупо. В нормальном мире это делается отдельной таблицей с привязкой по comment_id и уникальным ключом на comment_id + user_id.
6) Так как это комментарии, то использование varchar(255) для поля text - глупо. Нужен TEXT или LONGTEXT.
7) Отсутствуют поля даты создания и редактирования, что в будущем не позволит строить статистические данные или расширять функционал (разрешать менять текст комментария только в течении 5ти минут, например). На это надо закладываться заранее.

Это что касается структуры таблицы. Теперь по коду:
8) Сервис-локация (класс App), вместо нормального DI - это жесть. Скрытые зависимости говорят о невозможности тестирования такого кода.
9) "Магическая" константа 'comment' говорит о том, что потом такой код нормально не отрефакторить. Т.е. переименовываешь внутри что-то, а потом получаешь кучу ошибок и придётся лазать по коду и везде выгребать этот "get('comment')". И не дай бог где-то они получаются как-то иначе. Работы ещё на пол дня.
10) Метод getById говорит о том, что сущность должна возвращаться всегда. Однако, может так случиться, что её по указанному id просто не найдётся. Как следствие - нет нормальной обработки ошибок.
11) Мутабельное поле votes у comment (т.е. имеется прямой доступ к нему). Это говорит о том, что сущность очень сильно связана с БД, а значит любой рефакторинг таблицы ведёт к полному перелопачиванию всего кода.
12) Нет обработки ошибок во время сохранения сущности.
13) Метод vote - не лучшее название. Оно переводится и как глагол "голосовать" и как существительное "голос", что может запутать. Я бы переименовал в addVote. Хотя и так тоже норм.

Это всё, что касается вопроса "в чём недостатки такого решения". Ответ - почти на каждой строчке косяк.

Если есть вопросы - задавай, могу чуть поподробнее расписать что-либо.

Потому что одно - исходный текст ($result[0]), а другое - найденные группы (в данном случае - $result[1], т.к. остальные погашены)

__DIR__, Карл, константа __DIR__

RUN apt update && \
    apt install -y libjpeg-dev libpng-dev libfreetype6-dev

RUN docker-php-ext-configure gd \
    --enable-gd-native-ttf \
    --with-jpeg-dir=/usr/lib \
    --with-freetype-dir=/usr/include/freetype2

RUN docker-php-ext-install gd

Давным давно задавал этот вопрос. Отвечаю сам себе. В случае yield from он не захватывает return statment, объявленный в экспортируемом генераторе, в отличии от return.

В качестве аналогии
return $this->test();

Можно использовать такой вариант:

yield from $result = $this->test();
return $result->getReturn();