[12.x] Add Singleton and Scoped attributes to Container

[riasvdv]

Changes

This adds two new attributes to the container attributes: #[Singleton] & #[Scoped]. These can be added directly to a class you're resolving through the container, without needing to manually register them as a singleton or scoped instance through the container.

#[Singleton]
class MyService {
}

[github-actions]

Thanks for submitting a PR!

Note that draft PR's are not reviewed. If you would like a review, please mark your pull request as ready for review in the GitHub user interface.

Pull requests that are abandoned in draft may be closed due to inactivity.

[riasvdv]

@taylorotwell Test failure is a docker registry issue and unrelated

[rodrigopedra]

@riasvdv I like the idea.

I just don't like that the Container@isShared() method, which is a public method, ends up mutating the $scopedInstances property even if an instance is not yet resolved.

Some can call the Container@isShared() without resolving anything from the container. And it feels weird for a method that verifies state ("Is Shared?") to also mutate state.

IMO, it is best to mutate the $scopedInstances array within the Container@resolve() method.

Although that could mean calling the \ReflectionClass twice on the class being resolved.

---

EDIT:

I guess it won't matter at the end, as the $scopedInstances property is used to call unset() on the $instances property.

So having extra unresolved classes there won't hurt.

But still, it feels somewhat cumbersome.

[riasvdv]

Adding to the scopedInstances is exactly what the scope binding does: https://github.com/laravel/framework/blob/12.x/src/Illuminate/Container/Container.php#L451

This would happen anyway if you’re registering a scoped binding, whether you’re resolving the class or not.

As you said we could move it to the resolve method, but would require doing reflection again on the attribute

[rodrigopedra]

Adding to the scopedInstances is exactly what the scope binding does

Sure, but that is an "action" method, a method one calls expecting to mutate state.

Whilst one would not expect state to be mutated when calling Container@isShared() (by its name alone).

But, I guess at the end it doesn't matter.

I don't think there is much code calling Container@isShared() anyway. And the state mutation is inoffensive.

Also, as you said, we can avoid another reflection call.

[taylorotwell]

Thanks!