January 2024 release

What's Changed

• feature: check extra args before container by @g105b in #141

Full Changelog: v1.3.1...v1.3.3

Supply extra arguments to individual invocations

What's Changed

• feature: check extra args before container by @g105b in #141

Full Changelog: v1.3.1...v1.3.2

Functions without a type are ignored

In this minor patch release, we skip any functions on the ServiceContainer that do not have a return type noted. This is so, when extending your own ServiceContainer, you will be allowed to put logic in the constructor (constructors are not allowed to have a return type).

What's Changed

• tweak: skip methods without a return type by @g105b in #139

Full Changelog: v1.3.0...v1.3.1

LazyLoad is no longer required

The main feature to this minor release is to drop the requirement of the #[LazyLoad] attribute. This attribute's usage has been removed, due to the simplification of the library to utilise any public method on the service container class.

What's Changed

• Public methods are used instead of LazyLoad by @g105b in #135
• CI and matrix builds by @g105b in #134
• docs: update docs to point to new ci tools by @g105b in #136

Full Changelog: v1.2.1...v1.2.2

Minor tweaks and improvements

What's Changed

• maintenance: dependabot by @g105b in #102
• feature: set multiple services at once by @g105b in #104

Full Changelog: v1.2.0...v1.2.1

Chained loaders and generic return types

It's now possible to chain the loader functions in ServiceContainer classes. This means that the loader functions can in turn have their own typed parameters automatically injected, just like the go functions in webengine.

An improvement has been made the the use of docblocks - now your IDE will understand that the returned type from Container::get is the type that is requested in the parameter. One day PHP will support generics and we'll not need to depend on doc blocks.

What's Changed

• build(deps-dev): bump phpstan/phpstan from 1.8.0 to 1.8.1 by @dependabot in #90
• feature: chained loaders by @g105b in #94
• feature: implement generic return type by @g105b in #93
• build(deps-dev): bump phpstan/phpstan from 1.8.1 to 1.8.2 by @dependabot in #91

Full Changelog: v1.1.3...v1.2.0

Lazier LazyLoad

The new feature in this release is the "lazier" LazyLoad attribute. Before, the LazyLoad attribute was required to state the type of object it loaded, but now if there's a return type on the class itself, the type annotation in the attribute is not mandatory.

Along with this feature, the development dependencies have been set to a hard version constraint to help with predictable builds.

Nullable injections

This minor patch release allows nullable types to be requested by the Injector class. This means that if your function parameter has a type such as ?App\User, it will still try to inject the App\User class. This is super useful for WebEngine applications, allowing go functions to simply have a nullable User parameter to indicate whether on not the user is authenticated.

Lazy loading from class

This patch release allows the lazy loading feature from the previous release to be added to any class, by adding the #[LazyLoad(ClassName)] tag to any class.

Lazy loading

The main feature of this minor release is the lazy loader. Use the setLoader() method of the Container class to pass a callback that constructs your dependency, rather than having to have a pre-constructed object when using the set() method.

An often overlooked benefit of using service containers is the fact that, as the framework knows when and where a service is being requested, it doesn't actually need to construct the object until the first time it's requested.

A good example of where this will benefit is the Database. Using a lazy-loaded service container has two implementation benefits:

1. On pages that don't query the database, the database object is never constructed, so no connections are made to the database until they're used.
2. The framework can suggest default behaviour for the construction of objects, but if the developer wants to use a different implementation of the same interface, they are free to override it.

The other benefit is how the container is used: the developer can register their own classes in the container, again only being constructed at use-time, allowing much richer abstraction patterns like the Repository Pattern hiding any database implementations.