Dependency injection #4

c.fahner · 2026-04-25T15:12:20+02:00

c.fahner commented

2026-04-25 15:12:20 +02:00

Adds the InternalAssembler, which is the dependency injection implementation for this framework.

Implements slendium/framework#2. Adds the `InternalAssembler`, which is the dependency injection implementation for this framework.

c.fahner added 3 commits

2026-04-25 15:12:20 +02:00

Add phpstan.neon 3d001bf3eb

Add phpunit.xml cb985aec21

Add Assembler with related types and tests bf495d6b40

c.fahner added 1 commit

2026-04-25 15:14:07 +02:00

Update phpstan.neon 46dfc3a479

c.fahner changed title from ~~WIP: Issue 2~~ to WIP: 2 - Dependency injection

2026-04-25 19:02:59 +02:00

c.fahner reviewed

2026-04-25 20:23:37 +02:00

src/Application/Assembler/ImplementedBy.php

					
				@ -0,0 +13,4 @@

				 * @copyright Slendium 2026

				 */

				#[Attribute(Attribute::TARGET_CLASS | Attribute::IS_REPEATABLE)]

				final readonly class ImplementedBy {

Separate into ImplementedBy (requires a class-string) and MaybeImplementedBy (any string) to make explicit which implementations MUST exist and which ones MAY be provided by other libraries.

Separate into `ImplementedBy` (requires a `class-string`) and `MaybeImplementedBy` (any `string`) to make explicit which implementations MUST exist and which ones MAY be provided by other libraries.

Alternatively, every module type could be annotated with a list of service interfaces mapped to their implementation types.

Pros:

Avoids having to awkwardly put service implementations in namespaces defined from other code. The framework's UserService interface could, for example, point to Slendium\Framework\Services\Users\UserServiceImpl, which would have to be added to the composer file of any implementing package.
Inactive modules cannot be accessed accidentally, as they are not analyzed

Cons:

Every module has to be reflected every request
All mappings have to be in-memory on every request
Bureaucracy of maintaining a list of provided services for every module

The ImplementedBy model is a bit awkward in regards to namespacing, but constructs implementations on-demand.

Alternatively, every module type could be annotated with a list of service interfaces mapped to their implementation types. Pros: * Avoids having to awkwardly put service implementations in namespaces defined from other code. The framework's `UserService` interface could, for example, point to `Slendium\Framework\Services\Users\UserServiceImpl`, which would have to be added to the composer file of any implementing package. * Inactive modules cannot be accessed accidentally, as they are not analyzed Cons: * Every module has to be reflected every request * All mappings have to be in-memory on every request * Bureaucracy of maintaining a list of provided services for every module The `ImplementedBy` model is a bit awkward in regards to namespacing, but constructs implementations on-demand.

Going for the ImplementedBy model without the maybe-variant for now. It should be possible to provide DependencyResolver's from the configs, which will override any ImplementedBy attribute.

Additionally, the framework does not even have to provide a UserService if it simply provides the ability to intercept requests. An Auth module could be provided from the framework package itself which handles IP-address, origin and user validation. The default RequestInterceptor could be marked ImplementedBy for a class in this framework-provided module. If the module is inactive, this implementation won't be available and requests won't be intercepted. Using a custom RequestInterceptor would then require declaring an override using a resolver in the configs.

Going for the `ImplementedBy` model without the maybe-variant for now. It should be possible to provide `DependencyResolver`'s from the configs, which will override any `ImplementedBy` attribute. Additionally, the framework does not even have to provide a `UserService` if it simply provides the ability to intercept requests. An `Auth` module could be provided from the framework package itself which handles IP-address, origin and user validation. The default `RequestInterceptor` could be marked `ImplementedBy` for a class in this framework-provided module. If the module is inactive, this implementation won't be available and requests won't be intercepted. Using a custom `RequestInterceptor` would then require declaring an override using a resolver in the configs.

c.fahner marked this conversation as resolved

c.fahner added this to the v0.1 milestone

2026-05-01 15:57:30 +02:00

c.fahner started working

2026-05-01 15:57:34 +02:00

c.fahner reviewed

2026-05-01 16:04:11 +02:00

src/Application/DependencyResolver.php Outdated

					
				@ -0,0 +10,4 @@

				interface DependencyResolver {

					/**

					 * All dependent types satisfied by this resolver.

"An intersection of types satisfied by this resolver."

c.fahner marked this conversation as resolved

c.fahner reviewed

2026-05-01 16:19:35 +02:00

src/Base/Application/SingletonResolver.php

					
				@ -0,0 +16,4 @@

				final readonly class SingletonResolver implements DependencyResolver {

					#[Override]

					public array $satisfies;