он прям докблоки жрет? я думал выпилили с приходом атрибутов парсинг докблоков
это очень странно, потому что у нас точно так же есть trigger_deprecation симфонишный в вендоре https://drive.google.com/uc?id=1BZW_W4w9NPr3AdHlRYwuzGFkaT134lzo
модель из di?
а какой халявный апм дает наилучшее покрытие похапе?
сколько не задаюсь вопросом, но не нахожу ответа - те 3.5 процессорных такта, который сэкономятся бустрапе, и те 3.5 наносекунды, которые сэкономятся на отсутствии переподключ...
типа, юнион таблицу делать?
неужели отправка в кафку такой длительный процесс?
есть хоть одна орм, которая поддерживает select returning?
чятик, как хукнуть изменение публичного свойства?
кстати, а как вообще растет массив в пхп при добавлении новых объектов? не выделяет ли он память "заранее"? например, тот же дс преаллокейтил с запасом, чтоб на каждую вставку...
css уже тьюринг полный или еще пока нет?
как она могла бы выглядеть, например?
а в чем проявляется симптом проблемы? то есть он просто падает или некорректно находит ошибки?
> Очередь для отправки в брокер будет наполняться в одном потоке с приложением. может, создать табличку queue в базе данных и просто писать в неё?
там в ошибке есть строки only full group by ?
а чего тогда не phar не заюзать? конфликты со своими зависимостями?
или задрочит cpu на $wait = 0 ?
какой шанс, что трюк с unset + __get отъедет в ближайшей версии?
почему принтер не может получать аргументы?
а запрос он точно делает, все возвращают какой-то результат?