feat: add autowire/autodiscovery/auto-initialization of interfaces to classes

[Jeroen-G]

Rationale

First of all, it is exciting to play with this new framework! I like a lot of it already, but I hit one snag when building some services. I usually have an interface for them (for example to make mocking easier). But with Tempest it looks like this would require a initializer class. And I am too lazy to make those for all my services 😜
A while ago I made an Autowire implementation for Laravel (link) so I thought I would start porting that a little bit to Tempest. So this first PR adds the Autowire attribute which allows autodiscovery of classes (or maybe auto initialization is a name better fitting to Tempest).

Let me know what you think!

How to use it

GreetingController:

final readonly class GreetingController
{
    public function __construct(public GreetingInterface $service)
    {}

    #[Get('/greetings')]
    public function index(): View
    {
        return view('greeting.view.php')->data(greeting: $this->service->greeting());
    }
}

GreetingInterface:

interface GreetingInterface
{
    public function greeting(): string;
}

GreetingService:

use Tempest\Container\Autowire;

#[Autowire]
final class GreetingService implements GreetingInterface
{
    public function greeting(): string
    {
        return 'hello world';
    }
}

[brendt]

Oooh, I like this! I'll probably review the PR tomorrow, but I'm pretty confident I'll merge it :)

[coveralls]

Pull Request Test Coverage Report for Build 11112271316

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

• For more information on this, see Tracking coverage changes with pull request builds.
• To avoid this issue with future PRs, see these Recommended CI Configurations.
• For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

• 15 of 26 (57.69%) changed or added relevant lines in 2 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage decreased (-0.09%) to 81.385%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
src/Tempest/Container/src/AutowireDiscovery.php	10	21	47.62%

Totals
Change from base Build 11062628894:	-0.09%
Covered Lines:	5946
Relevant Lines:	7306

---

💛 - Coveralls

[yassiNebeL]

Oooh, I like this! I'll probably review the PR tomorrow, but I'm pretty confident I'll merge it :)

I appreciate your contribution @Jeroen-G! However, Tempest already has a Singleton attribute that handles service injection directly into the container. Could you clarify how this autowiring feature complements or improves upon that, and whether it addresses scenarios where the existing attribute falls short?

[Jeroen-G]

Oooh, I like this! I'll probably review the PR tomorrow, but I'm pretty confident I'll merge it :)

I appreciate your contribution @Jeroen-G! However, Tempest already has a Singleton attribute that handles service injection directly into the container. Could you clarify how this autowiring feature complements or improves upon that, and whether it addresses scenarios where the existing attribute falls short?

Did you try out the example in the PR description? That is something the Singleton attribute cannot do. Automatically wiring interfaces to implementation is different from registering a singleton implementation. So that is where this feature complements upon :)

[Jeroen-G]

Could you give a code example?

[shaffe-fr]

This PR allows to tell the container: when I want a GreetingInterface give me this implementation.

[brendt]

This is great!

I've got one idea though I wanted to pitch though, but I'm not sure I like it myself.

I don't really like too many attributes on a class. I was wondering if it would make sense if we combined the autowiring attribute and singleton attribute into one, something like:

#[Singleton(for: Interface::class)]

I don't think it's better than this, but I wanted to pitch the idea just in case.

[Jeroen-G]

This is great!

I've got one idea though I wanted to pitch though, but I'm not sure I like it myself.

I don't really like too many attributes on a class. I was wondering if it would make sense if we combined the autowiring attribute and singleton attribute into one, something like:

#[Singleton(for: Interface::class)]

I don't think it's better than this, but I wanted to pitch the idea just in case.

Pragmatically I could go with this. Conceptually however a singleton is meant to restrict instantiation of a class to one instance, which I think is not necessarily the case here. If you would like to merge them, I would propose:

#[Autowire(singleton: true)]

Semi-related, if this gets merged I would also look into opening a new PR for a Configure attribute.

[brendt]

I actually think just making the combination of both attributes #[Autowire] and #[Singleton] will be the best approach, as it causes the least confusion, and prevents one thing from being done in two ways.

Not sure yet how I feel about #[Configure], but let's open a new discussion for it :)

Btw: are you on Discord?

[brendt]

I think we're ready to merge? Can you rebase the branch on main?

[brendt]

Super nice! I'll write some docs for this as well :)

[Jeroen-G]

Cool! Thanks, and I see you already found my discord handle :)