Allow something like "real" DI

[pmjones]

Per #280 and the comments therein, this enables something like "real" constructor DI for FastRoute.

[lcobucci]

@pmjones I'm sorry for the delay.

I've didn't manage to play with these changes locally to validate them yet, but your proposal brings runtime implications...

I didn't think about them properly on my comment also but by expecting an instance we'll force operations and memory allocation to bootstrap things, which would in the not necessarily be needed (e.g. when dealing with caching).

We also are now opening things for state mutation (through the creation of new instances, sure), which will have more function calls to do the operations - which will also add some small performance impact.

Given this project aims to be a low-level solution, I'm not sure if the benefits outweigh the costs...

Does this make sense to you?

[pmjones]

@lcobucci First, no problem on the delay -- we all are busy. :-)

Second, thanks for your patience and consideration. As always, please feel free to ignore any of my suggestions; it's your project, and your judgment will decide.

Having said all that:

by expecting an instance we'll force operations and memory allocation to bootstrap things, which would in the not necessarily be needed

Yes, I get what you mean. I considered using a separate Service Locator object instead of the individual dependencies; something like that would let you create the main FastRoute container, and delegate object creation to the Service Locator, which would not create any of the dependent objects until the FastRoute container asks for them. I thought it would be a little indirect, but it would meet two goals:

1. Not creating unnecessary objects (well, except for the Locator itself).
2. Any DI system can build up the Locator however it wants, so long as it matches the Locator interface.

If you're open to reviewing the idea, I'll submit a separate PR for it.

performance impact

Yes, more objects/mutations will necessarily reduce performance. My experience and intuition make me think the reduction will be negligible when it comes to the system as a whole. Of course, we'd need to measure and compare to see the exact impact.

Again, thanks for your time in looking these over in the first place.

[pmjones]

@lcobucci The alternative PR at #283 should address your concern about "not creating unnecessary objects" by moving the DI functionality to a separate Settings object. The one presented in the PR mimics the existing object-creation logic in FastRoute, and allows consumers to create their own using the DI system of their choice.

Please let me know if this variation is an acceptable alternative, and thanks again for indulging my offerings here.