Environment-based Dependency Injection

[adragus-inviqa]

Since we now have the DI system creating the objects and the system being tight to the environment, do you think it's worth having an environment-aware DI system?

Is there something in the current codebase that handles such "conditionals"?

It would facilitate custom object creation along the pipeline. Some examples:

• different log object for develoment (DEBUG, text), CI (info, text) and production (ERROR, 3rd party)
• different email implementations for development (to file) and production (to email server)
• payment mocks on development

The DI system could rely only on $_ENV for this and it will still be pretty awesome. Otherwise, some other sub-system would take care of this and it wouldn't be right, because it's the DI who should decide what object goes where and when. Something similar to the layout's ifconfig.

I'm not sure about the implementation though, as, for example, preference is a 1-to-1 relationship. Keeping BC, maybe something like this is possible to implement (assuming $_ENV['ENV_TYPE'] is set to dev, ci or prod):

<preferenceIf for="\My\LoggerInterface" switch="ENV_TYPE" default="dev">
    <dev>\My\FullLogger</dev>  <!-- or <case value="dev">\My\FullLogger</case> -->
    <ci>ciLoggerVirtualType</ci>
    <prod>\Some\ThirdPartyLogger</prod>
</preferenceIf>

For now I'm thinking that this could be done for preference only, not type or virtualType.

I think it would be a shame to let such a flexible DI become a... static thing.

What do you think?

[antonkril]

Agree that it should be easy to configure different behaviors for system for different environments, but performance is critical for ObjectManager because it's called thousands times per request. So we try to keep feature set of OM minimal.

This environment-dependent feature has limited scope (not so many things should be different for dev and prod) so it will be used for 3 to 20 classes (~0,03%). But the conditional logic that will check whether there is environment-specific configuration for some type will be executed for each object created during request. So my opinion is that such features should be built on top of OM with conditional factories that take init params from env.php and decide which object type to create.

Do you have full list of objects that you would like to be able to easily configure for different environments?

[nevvermind]

Do you have full list of objects that you would like to be able to easily configure for different environments?

I don't. Even if I did, I don't think my list would've been complete, considering the large audience here.

So my opinion is that such features should be built on top of OM with conditional factories that take init params from env.php and decide which object type to create.

This, too, is an option. Anything but a blind DI system.
I did look at the init_param arg type and I'm assuming it's planned for further changes, because now it's a more or less a const arg type, unless I missed something.

Also, it doesn't all have to be at runtime. The DI compiler could very well transform such conditional nodes (preferencesIf in my example) into plain preference ones, at compile time - then cache it or whatever. M2's auto-generating PHP - why shouldn't it generate XML too?
But I'm sure your suggestion is easier to implement.

PS: I've two accounts. Forgot I was on this one.

[antonkril]

Init_param is different from const. It receives name of the constant that contains name of argument in init parameters of application (env.php, $_SERVER). So if you want to inject some of application's init_params to object you use init_param argument type in di.xml.

As for using compiler to fix performance, it's possible but it will increase complexity of both OM and compiler.

By the way in some sense compiler generates xml. It merges di.xml contents with constructor signature information (collected with reflection), optimizes it and stores it in fast format (not in xml), then reads it instead of di.xml. And this is main function of compiler (not code generation)

[nevvermind]

Wait a nanosecond!

So this argument maps to this constant, and that MAGE_MODE is fetched from whatever options the app was initialized with (like you said, env.php and $_SERVER).

The documentation says only Global application argument represented by Constant::NAME looked up and passed as argument. Now I get it.

This clears my problem quite a bit.

[antonkril]

I'll close issue, since init_param allows you to achieve at least similar behavior. But please feel free to reopen it or better post question on forum if you still think it should be better investigated.