lucatume / di52 Goto Github PK

While it makes sense on the back-compatibility front, the autoloading of the aliases.php file will create problems in some contexts, e.g. when using Strauss to prefix it.

Introduction

Looking at the Dependency Graph (which excludes private packages, but it's a somewhat reliable source of information), DI52 is mostly used in the WordPress environment.

PHP 5.2 is used in 0.8% of WordPress websites today. Outside the WordPress environment that's pretty much consistent.

Having PHP 5.2 compatibility made a lot of sense when DI52 was released, because that was the minimum PHP version for WordPress. Since April 2019, with the release of WordPress 5.1, the minimum PHP version was raised to 5.6.

Why am I opening this now?

DI52 adds an annoying and no longer maintained dependency to a project, which is xrstf/composer-php52. This is not a development dependency, this is a REAL dependency that's added on all projects that depend on DI52.

I, as a developer of WP STAGING, want to use DI52, but I don't want to depend on xrstf/composer-php52 because our minimum PHP version is 5.6.

What to do about it

1. I can fork it and create a Luc45/DI56, for which I would ask your blessing to do so.
2. You create a lucatume/DI56 repository which is an exact copy of DI52 but with composer5-3.json as default, and I will happily contribute to it.
3. We move xrstf/composer-php52 to suggest in composer.json, add a php-52-compatibility.md file in the project, explaining that for PHP 5.2 compatibility the person should add the scripts portion in his composer.json and install it with composer update --install-suggests.

When the container auto injects a dependency, it returns a new instance of the dependency by default. (bind behavior)

Most of the cases, however, I'd like to inject the same instance (singleton behavior).

I'd like to propose a feature, which is to define the default behavior for auto resolving when creating an instance of the Container:

class tad_DI52_Container {
    public function __construct( $autoResolveAsSingleton = false ) {
        $this->autoResolveAsSingleton = $autoResolveAsSingleton;
    }
}

$container = new tad_DI52_Container( true );

Before I jump into trying to come a PR for this, I'd like to ask for feedback on this idea.

Thanks.

It seems this dependency breaks Composer 2 support:

The project's readme makes it seem like they don't have plans to fix it: https://github.com/composer-php52/composer-php52

Hi Luca,

This is an old issue I've always faced with DI52.

Consider the following scenario:

class Car {
	public function __construct( Engine $e ) {}
}

class Engine {
	public function __construct( NonExisting $g ) {}
}

$container = new tad_DI52_Container();
$container->make( Car::class );

( ! ) Fatal error: Uncaught RuntimeException: Error while making 'Car': 'Car' is not a bound alias or an existing class. in /shared/httpd/di52/htdocs/di52/src/tad/DI52/Container.php on line 352

The exception tells me that Car doesn't exist, where actually the problem is in my Engine because it depends on NonExisting.

An explicit binding throws an accurate error:

$container = new tad_DI52_Container();

$container->bind( Car::class, function ( tad_DI52_Container $c ) {
	return new Car( $c->make( NonExisting::class ) );
	// or return new Car( new NonExisting );
} );

$container->make( Car::class );

( ! ) Fatal error: Uncaught RuntimeException: Error while making 'NonExisting': Class NonExisting does not exist in /shared/httpd/di52/htdocs/di52/src/tad/DI52/Container.php on line 352

I might come up with a PR for it, but I felt like sharing this here first to give you a head start in case you want to look into this yourself.

when providing afterbuildmethods to a bindDecorators call, once the container creates the instances, the afterbuildmethods are only called on the base class. the afterbuildmethods should be called on the first decorator so the calls goes down the chain, ultimately to the base class as last one.

This test fails:

/** @test */
public function it_should_respect_singletons_when_auto_resolving() {
	$c = new tad_DI52_Container;

	$c->singleton(Dependency::class, function() {
		return new Dependency;
	});

	$parent = $c->make(Depending::class);
	$parent2 = $c->make(Depending::class);

        // Failed asserting that two variables reference the same object.
	$this->assertSame($parent->getDependency(), $parent2->getDependency());

	// If not using a closure, the test would pass:
	//$c->singleton(Dependency::class, Dependency::class);
}

This is because offsetGet calls the callback to get the instance of Dependency, which returns a new instance.

If the callback was executed already, it should save that instance in the singletons array and return from that.

Before I try to open a PR for it, can you please confirm this is not the expected behavior, and that test should be passing?

It would be great if this could apply the https://github.com/stellarwp/container-contract interface for use with StellarWP packages.

On this repo's "About" (that shows in the sidebar) it says A PHP 5.2 compatible dependency injection container..

It should be PHP 5.6.

You probably have this in mind already, but I rather open this as an issue just to make sure these details don't fall between the cracks and get forgotten.

There's a PSR for Dependency Injection Containers. It would be nice if DI52 3 could implement it.

See: https://www.php-fig.org/psr/psr-11/

When you have a class Class which depends on class Dependency and call Class 2 times, it will have the same instance of Dependency injected.

Please check the attached zip for proof. It's just printing a random number. container-make-test.zip

This is how it should be done? It's quite misleading when you have many dependencies not registered as singletons and I'd consider it a bug.

Due to a PHP limitation, when using ReflectionClass on a class that has a syntax error that prevents PHP from parsing it (as with lexical errors, unexpected tokens), it throws a ReflectionException saying that The class does not exist:

[27-Nov-2020 12:23:53 UTC] PHP Fatal error:  Uncaught RuntimeException: 'WPStaging\Pro\Snapshot\Ajax\Delete'
	 => 'WPStaging\Pro\Snapshot\Service'
	 => Error while making 'WPStaging\Pro\Snapshot\Site\Service\SnapshotService': Class WPStaging\Framework\Filesystem\Filesystem does not exist in /var/www/single/wp-content/plugins/wp-staging-dev/vendor/lucatume/di52/src/tad/DI52/Container.php:356
Stack trace:
#0 /var/www/single/wp-content/plugins/wp-staging-dev/vendor/lucatume/di52/src/tad/DI52/Container.php(281): tad_DI52_Container->resolve('WPStaging\\Pro\\S...')
#1 /var/www/single/wp-content/plugins/wp-staging-dev/Pro/Snapshot/SnapshotServiceProvider.php(35): tad_DI52_Container->make('WPStaging\\Pro\\S...')
#2 /var/www/single/wp-content/plugins/wp-staging-dev/Framework/DI/ServiceProvider.php(10): WPStaging\Pro\Snapshot\SnapshotServiceProvider->addHooks()
#3 /var/www/single/wp-content/plugins/wp-staging-dev/vendor/lucatume/di52/src/tad/DI52/Container.php(484): WPStaging\Framework\DI\ServiceProvider->register()
#4 /var/www/single/wp-content/plugins/wp-stagin in /var/www/single/wp-content/plugins/wp-staging-dev/vendor/lucatume/di52/src/tad/DI52/Container.php on line 356

In reality, the error was a missing semi-colon on the WPStaging\Framework\Filesystem\Filesystem class.

I suggest we try to improve this error message, saying something like Could not reflect class XYZ. This class might have a syntax error, or might not exist.

I can open a PR for this in the next couple of days.