Autoload-based automatic registration of service dependencies about di HOT 5 OPEN

Solving your problem needs either ignoring files which use not autoloadable classes by configuration on your side or using static reflection and ignoring incomplete classes on Nette side.

Registering class as a service because some service relies on it is unreliable. It could work, but only with non-abstract classes. Even requiring interface instead of its implementation would break that magic. Context-specific dependencies like ORM entities would probably pass automatic registration, but who wants entities registered as services?

Btw, RobotLoader in SearchExtension is used just to find classes in a folder, not for actual autoloading. Problem is on php level - loading php files requires php to resolve references (e.g. extending phpunit test case), which triggers all autoloaders (composer in your case) and fails on missing class. That's why static reflection would be needed if solved on Nette side.

from di.

Solving your problem needs either ignoring files which use not autoloadable classes by configuration on your side

The search extension does not really allow ignoring files:

• [exclude](

  di/src/DI/Extensions/SearchExtension.php

  Line 108 in 1b2d371

  && (!$rejectRE || !preg_match($rejectRE, $rc->name))

  ) only applies after loading the class has been attempted, and
• the extension only really allows controlling the acceptFiles parameter of RobotLoader, which does not allow negative globs as far as I can tell.

Registering class as a service because some service relies on it is unreliable. It could work, but only with non-abstract classes. Even requiring interface instead of its implementation would break that magic.

Good point, but I would expect most of abstract classes/interfaces will have more than one implementation and then the SearchExtension would fail just as well.

Context-specific dependencies like ORM entities would probably pass automatic registration, but who wants entities registered as services?

Right, but again I am interested in this specifically as an opposition to SearchExtension which will have the exact same downside if you pass src/ to it without any excludes.

Btw, RobotLoader in SearchExtension is used just to find classes in a folder, not for actual autoloading.

Yes, I am aware, which is why I specifically tried to talk about registration, not loading.

The extension I propose would just replace the in-advance file system search with looking at dependencies of explicitly registered services (transitively). And instead of file system path prefix, it would be limited by PHP namespace prefix.

Problem is on php level - loading php files requires php to resolve references (e.g. extending phpunit test case), which triggers all autoloaders (composer in your case) and fails on missing class. That's why static reflection would be needed if solved on Nette side.

I am not really sure if this is something Nette should be expected to solve. After all, having a Nette app and a library with optional dependencies in the same src/ directory is pretty unorthodox.

But either way, it is orthogonal to this proposal. Here I am mostly interested in getting rid of RobotLoader since I do not find it very useful.

Another benefit to this would be that it would make the container smaller than the equivalent use of SearchExtension, unless one is meticulous about excluding every class they do not need – but then you might as well register just the classes you need manually. Automatic registration of dependency classes in a certain namespace would only register actual dependencies.

from di.

I will add to SearchExtension the option to exclude files as well, I thought it was there a long time ago.

The latter is based on RobotLoader, which, in addition to repeating the work already done by Composer in most modern projects, can cause issues when some of the classes are not loadable.

That's not true. Composer's role and capability is not to provide a list of all classes in an application.

from di.

Composer's role and capability is not to provide a list of all classes in an application.

Yes, but I would argue most apps will know the list of classes statically so getting a list of classes only matters in two cases (AFAICT):

• A class takes an abstract class/interface as a dependency.
  • But unless there is only a single implementation, the mapping would still need to be resolved manually, thus the class name would be also known statically.
• App supports installing extensions at run time by copying them into a subdirectory.

from di.

But unless there is only a single implementation, the mapping would still need to be resolved manually, thus the class name would be also known statically.

And how are you going to find out that there is only one implementation and what is its class name without a list of all the classes?

from di.