Laravel Request — как работает?

Question

[oloref]

Есть такой код:

$request1 = Request $request; // представим, что сюда request попал через сервис контейнер
$request2 = Request $request; // представим, что сюда request попал через сервис контейнер

$request1->merge(['1' => 1, '2' => 2]);
dump($request1);

$request2->merge(['3' => 3, '4' => 4]);
dump($request2);

Дамплю, как видно, два разных объекта класса Request.

Но в параметрах $request1, лежат такие данные
1 => 1
2 => 2

А в $request2
1 => 1
2 => 2
3 => 3
4 => 4

Почему в $request2 попали ключи и значения, которые я задавал для первого реквеста?

Answer 1

[Владимир Римидалв]

Потому что у тебя в request1 и в request2 лежит индекс одного и того же объекта https://www.php.net/manual/ru/language.oop5.refere...

Comments

[oloref]

Это специфика именно класса request? Это что-то похожее на singleton?

[Владимир Римидалв]

oloref,

Это специфика именно класса request

это специфика классов в PHP открой ссылку и ознокомься с документацией
Касательно твоего примера - покажи весь код, который работает описанным тобой образом

[oloref]

Владимир Римидалв, не, про ссылки в PHP я понял. Код, который я написал, используется в laravel контроллере обычном, а request - это ларавеловский request, и мне интересно, как он работает

[Владимир Римидалв]

oloref,

это ларавеловский request, и мне интересно, как он работает

ну раз это класс, то работает как и любой другой класс в пхп, поэтому ответ на твой вопрос

Почему в $request2 попали ключи и значения, которые я задавал для первого реквеста?

- дан
Вот тебе дока на сам класс https://laravel.com/api/10.x/Illuminate/Http/Reque... если вдруг ты что-то хочешь дополнительное узнать, но сформулировать не можешь

[Алексей Уколов]

мне интересно, как он работает

Это singleton. Тут дело не в том, как работает класс Request, а в том, как работает его резолв внутри Laravel. Поскольку это фундаментальный класс, то его инициализация раскидана по всему фреймворку и сложно дать конкртеную ссылку на код, но в более простом случае нужно смотреть сюда: https://laravel.com/docs/11.x/container#binding-a-...

[oloref]

Алексей Уколов, Вот мне было интересно как работает именно его резолв. Обычно же ларавеловский контейнер работает так, что создаёт инстансы классов при указании в конструкторе этих классов. А request ведёт себя как singleton, но я хотел знать точно - это singleton или нет.

[Алексей Уколов]

Обычно же ларавеловский контейнер работает так, что создаёт инстансы классов при указании в конструкторе этих классов. А request ведёт себя как singleton

Как автор кода сущность в контейнере зарегистрирует, так она и будет резолвиться: не укажет ничего особого, будет создаваться новый объект каждый раз, а захочет - зарегистрирует как синглтон. Как я уже сказал, в случае с Request всё сложнее, чем просто регистрация синглтона через метод контейнера, но суть такая же.

[Ипатьев]

Алексей Уколов, что за чушь, никакой это не "синглтон". В ответе всё правильно написано.
Точнее он может быть синглтоном, или не быть но к ответу на вопрос это отношения не имеет

[Алексей Уколов]

Ипатьев, то, что это синглтон (а это синглтон на практике), не противоречит написанному в ответе.
Автор вопроса же написал, что про ссылки ему понятно, ему непонятна оркестрация внутри фреймворка, я именно этот аспект и уточнял.

Дамплю, как видно, два разных объекта класса Request.

Вот в чём заключается суть непонимания - oloref думает, что ему контейнер на каждый "запрос" создаст новый экземпляр объекта. Однако, это не так, и паттерн, когда это не так, называется синглтоном и именно его использование приводит к такому поведению. Не понимаю, откуда негодование ¯\_(ツ)_/¯.

Если объект в контейнере не зарегистрирован как синглтон, то если его вызвать дважды в одном методе, мы получим два разных объекта и поведение будет не такое, как описано в вопросе. Следовательно, дело всё же в синглтонности конкретного объекта в рамках конкретного контейнера. А из этой синглтонности уже следует и модификация по ссылке.

[Ипатьев]

oloref, вам ответили уже сто раз. реквест работает как и любой другой класс в пхп
А вот вы "про ссылки" так ничего и не поняли.

$obj = new stdClass();
$user1 = $obj;
$user1->a = 1;
$user2 = $obj;
$user2->b = 1;
var_dump($user1); // ШАЙТАН!!!

[Ипатьев]

Алексей Уколов, что ему непонятно, он написал в вопросе: "представим, что сюда request попал через сервис контейнер".
То есть это экземпляр одного и того же класса. А синглтон это или нет - для нас не принципиально.
И автор, кстати, неправильно понимает само понятие синглтона. Для него это "сущность, всегда автоматически доступная из воздуха". А не "сущность, которая может существовать строго в одном экземпляре".

[Алексей Уколов]

Ипатьев, я как раз этот момент более подробно раскрыл в комменте выше.

"представим, что сюда request попал через сервис контейнер". То есть это экземпляр одного и того же класса.

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

[Ипатьев]

Алексей Уколов, правильно. Важно же, что это один и тот же экземпляр. Только один и тот же не потому, что "синглтон", а потому что лежит в контейнере.

[Алексей Уколов]

Только один и тот же не потому, что "синглтон", а потому что лежит в контейнере.

Ипатьев, нет, ровно наоборот - он "лежит в контейнере" только потому, что он синглтон:
https://github.com/laravel/framework/blob/3d800c5b...
https://github.com/laravel/framework/blob/3d800c5b...
https://github.com/laravel/framework/blob/3d800c5b...
"Лежит в контейнере" и "синглтон" - это синонимы и первое является деталью реализации второго.

Если бы не был синглтоном, то нигде бы не лежал и указанного поведения бы не наблюдалось, потому что контейнер Laravel в таком случае бы создал два разных объекта.

[Ипатьев]

"being managed as a singleton" не означает что сам по себе объект является синглтоном :)
Это внутренняя кухня контейнера. Которая всего лишь означает вполне логичное поведение, когда при запросе сервиса надо отдать существующий, а не городить новый. "синглтон" в данном случае - это дефолтное поведение контейнера. Иначе это был бы не контейнер, а фабрика.
В любом случае, вопрос был про сам реквест, а не про работу контейнера.

Хотя возможно непонятки автора в том и заключаются, что он думал, будто контейнер каждый раз создает сервис заново. Хотя совершенно непонятно - зачем.

[Алексей Уколов]

контейнер каждый раз создает сервис заново

Ипатьев, ну да, мне кажется очевидным из написанного им, что он ровно так и думал.
Более того, по ссылкам выше прекрасно видно, что именно так контейнер Laravel и работает по-умолчанию :)

"синглтон" в данном случае - это дефолтное поведение контейнера

Неа, не дефолтное: https://github.com/laravel/framework/blob/3d800c5b...

Иначе это был бы не контейнер, а фабрика.

Это уже к Тейлору :)

[oloref]

Удивляюсь, как вы поняли, что было у меня в голове))
Спасибо, джентельмены, есть о чём подумать

[oloref]

Ипатьев,

Хотя возможно непонятки автора в том и заключаются, что он думал, будто контейнер каждый раз создает сервис заново. Хотя совершенно непонятно - зачем.

Вы совершенно правы.

А если вдруг мне понадобится два разных инстанса одного класса, нормальным будет сделать так?:

public function __construct(UriCutter $uriCutter, UriCutter $uriCutter2)
{
    $cutter1 = $uriCutter;
    $cutter2 = $uriCutter2;

    dump(spl_object_id($cutter1));
    dump(spl_object_id($cutter2));
}

Здесь при дампе уже выдаёт разные айдишники, то есть как я думал изначально будет работать контейнер. Но хотелось бы узнать, нормальная ли это практика.

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

[Ипатьев]

В чем смысл строк
$cutter1 = $uriCutter;
$cutter2 = $uriCutter2;
?

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

[oloref]

Ипатьев, просто было интересно, может есть другое решение. Понял, спасибо большое

[Ипатьев]

oloref, варианты есть, например пресловутая фабрика, которой утыкана вся ларавля.
Но для вариантов надо понимать задачу.

[Алексей Уколов]

Ипатьев, всё, теперь я понял, о чём вы говорили. Я-то думал, что автор вопроса так и делает — дважды резолвит из контейнера объект запроса. Но теперь смотрю в вопрос и вижу, что нет.
Я думал, что там примерно такой код:

$request1 = make(Request::class);
$request2 = make(Request::class);

А там, видимо, предполагался такой:

public function __construct(Request $request)
{
    $request1 = $request;
    $request2 = $request;
}

Тогда да, конечно, синглтон абсолютно ни при чём.

[Алексей Уколов]

@oloref:
А если вдруг мне понадобится два разных инстанса одного класса, нормальным будет сделать так?:

public function __construct(UriCutter $uriCutter, UriCutter $uriCutter2)

А вот тут уже зависит от контейнера - если объект в нём зарегистрирован как синглтон, то такой код всё равно вернёт две ссылки на один и тот же объект.
Если же вы хотите получить два разных инстанса синглтона, то тут уже придётся заморачиваться, но в реальности такой задачи обычно не стоит - не зря же разработчик сделал объект именно таким.

[oloref]

Алексей Уколов, Ну да, получить два синглтона было бы забавно)