Максим Федоров

Чтобы спрятать значение от возможности переопределить есть одно место...
static переменная внутри функции

it depends

• если запросы зависимые, то в цикле
  
• если запросы можно выполнить "параллельно", то можно асинхронно сделать сразу все 4 запроса и подождать самый медленный
  

например через multi curl, тогда все 4 запроса будут выполняться за время самого медленного из них, а не за сумму времени, удобно через Guzzle Async

$promise1 = $client->getAsync('http://www.example.com/foo1');
$promise2 = $client->getAsync('http://www.example.com/foo2');
$promise3 = $client->getAsync('http://www.example.com/foo3');
$promises = [$promise1, $promise2, $promise3];

$results = GuzzleHttp\Promise\settle($promises)->wait(); // тут все результаты

в обоих случаях не понятно, зачем таймаут, тк синхронно второй запрос начнется только ПОСЛЕ выполнения предыдущего, а в асинхронном варианте они просто выполнятся "одновременно" и вы получите результат сразу от всех запросов... таймаут ни к селу ни к городу

Данный вопрос не совсем относится к докерам или обновляениям папок через Шторм... а просто удобства с пакетом, который вы и саппортите

Ошибки:
- нужно писать тесты, чтобы предупредить ошибки :)

Постоянные муки:
- вообще, если библиотека супер-активно пишется и часто, то это немного отдаленно напоминает и нарушает принцип из чистой архитектуры "обращайтесь к стабильным зависимостям"

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

Совет:
сделайте не композер пакетом, а просто как сабрепозиторий, тогда любой из проектов просто как сабгит подтянет... при этом из каждого можно будет ее редактировать и не тянуть как вендор :) все равно она в рамках ваших репозиториев, зачем пакет? :)

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

Выполнил. С этим расчетом он и вводился — резолвить одинаковые названия. Вы СМОГЛИ в скрипте использовать одинаковые названия, что и нужно было от неймспейсов… подключили один класс из одного неймспейса и другой с таким же названием

А то, что вы хотите опустить неймспейс (игнорировать его суть) — это вопросы к вам… то, что можно неймспейс выносить в секцию use — это оптимизация, чтобы визуальный мусор неймспейсов убрать… очевидно, при явном конфликте эту оптимизацию не допустить

Вы можете или с неймспейсом юзать оба
Или добавить as

use MyPHPProject\Strings as MyStrings;
use AnotherPHPProject\Strings;

readonly для свойства класса,
перезаписать свойство с объектом в значении — значит записать туда ДРУГОЙ объект. Эквивалентность для объектов определяется хэшем
Объект тот же? Тот же. Значит мы не перезаписали!

($this->accountHandler)($id)

Делается одной итерацией (особенность работы isset (оператор ??), которая позволяет нам не ходить повторно по массивам)

$data = [ /** **/];

$res = array_values(array_reduce($data, function (array $acc, array $item) {
    $item['count'] = ($acc[$item['id']]['count'] ?? 0) + $item['count'];
    $acc[$item['id']] = $item;

    return $acc;
}, []));
var_dump($res);

https://onlinephp.io/c/39f04

Можно через foreach, если прямо хочется

$data = [ /** **/];

$res = [];
foreach($data as $datum) {
	$datum['count'] = ($res[$datum['id']]['count'] ?? 0) + $datum['count'];
	$res[$datum['id']] = $datum;
}

var_dump(array_values($res));

Можете подключить другие адаптеры и совместить работу WebDav с ними
Например AWS S3
https://flysystem.thephpleague.com/docs/adapter/aw...

То есть работать внутри flysystem и перемещать файлы, если вам нужно

$filter = function(string $input, string $attr) {
	return implode(' ', array_reduce(explode(' ', $input), function(array $acc, string $selector) use($attr) {
		$acc[str_starts_with($selector, $attr) ? $attr : $selector] = $selector;

		return $acc;
	}, []));
};

var_dump($filter('any1 col-12 any2 col-4 any3 col-7 other', 'col-'));
var_dump($filter('any1 col-12 any2 col-4 any3 col-7 other col-7 col-7', 'col-'));

что за формат такой Iterator и как с ним взаимодействовать?

итерироваться

$iterator = $reader->fetchColumnByName('title');
foreach($iterator  as $item) {
     var_dump($item);
}

А это первая ссылка в гугле по запросу iterator php
https://www.php.net/manual/ru/class.iterator.php

По второму вопросу — походу не найдена такая колонка в хедере
Вот код, который кидает его:
https://github.com/thephpleague/csv/blob/4b5d1df71...

прдебажьте

У вас очень логичный вопрос на счет сеттера: сеттер полностью уничтожает задумку с инкапсуляцией. Правильно это называется "семантическое нарушение инкапсуляции" — то есть как-бы мы инкапсулировали, но по факту назад открыли прямую запись в свойство напрямую. Все доводы "ну мы можем в сеттере валидировать" не корректны

Правильным способом будет не использовать сеттеры. Вот моя статья на эту тему:
https://habr.com/ru/post/469323/

Более подробно: каждый класс нужно проектирвовать так, чтобы данные внутри были максимально связаны. Например каждый метод работать должен в хорошем случае с максимальным числом полей класса, тогда у него высокий cohesion... В тоже время снаружи наужно работать с максимальн омалым числом метода, тогда будет низкая связанность (coupling). Это пара принципов из GRASP.
Когда вы делаете сеттеры и геттеры, то у вас данные внутри между собой почти никак не взаимодействут: с геттером работают снаружи, с сеттером работаю снаружи — весь класс нараспашку, а в нем в 100% случаев появляются данные, которые вместе не должны находиться и никак не связаны — анрушена и абстракция и инвариант и много чего еще...

Про инвариант отдельно: например есть платеж, у него есть значение, с которым платеж инициирвоан (initValue), есть значение холда (holdAmount) и есть значение чарджа на списание (chargeAmount)
Когда вы работаете с платежом, контролируя ивнариант в самом классе, то ваш каждый метод првоеряет др значения и позволяет перейти к др состоянию... методов будет 2-3, все инкапсулировано и безопасно.

Например:

class Payment {
     pub func charge(amount int) void {
          if (this.holdAmount < amount && this.initAmount < amount) {
               throw new PaymentException('Unavailable charge amount')
          }

           if (this.status === PaymentStatus:finish) {
               throw new PaymentException('Payment already fisnished')
          }

          this.chargeAmount = amount
          this.holdAmount -= amount
          this.status = PaymentStatus:finish
     }
}

Тут в одном методе полные проверки и класс сам контролирует все состояние внутри, также соблюдается закон Деметры. У даннго кода высокий cohesion (из GRASP), тк внутри идет плотная работа с внутр данными (значит они корректно тут закроекны) и низкий coupling ( с теми данными для данного кейса только один метод работы, все внутри)

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

Вы можете воспользоваться Guzzle и middleware MultipartStream
https://github.com/guzzle/psr7#multipartstream

Как работать со стримами:
https://docs.guzzlephp.org/en/stable/psr7.html?hig...

Может до, может после

Данные серверу (пользователю) можно отправить через fast_cgi_finish_request, но приложение продолжит работать — очевидно объекты продолжат существовать столько, сколько нужно и удалены (если пришёл gc, а на объект никто не ссылается)

Кроме того у вас может быть демон, который вообще не работает с веб-сервером… очевидно что объекты будут существовать без связи с клиентом

В общем случае (классич работа приложения) после того как закончится выполнение — fpm прибьёт ваш процесс и объекты соотвественно — и будет вызван деструктор

Вы можете и сами инициализировать деструктор через удаленние объекта через unset

В режиме, когда пхп-скрипт работает достаточно долго (или в cli режиме или после finish request) — gc может прийти за брошенными объектами сам и вызвать деструкторы

Почитать:

https://abhishekjakhotiya.medium.com/php-fpm-shutd...

https://www.php.net/manual/ru/features.gc.performa...
https://developpaper.com/garbage-collection-mechan...

gc = garbage collector = сборщик мусора