Not sure about this one. It's kind of equivalent to ContainerAwareCommand, that we don't need for deprecating it (the core is ready for that).

It's kind of equivalent to ContainerAwareCommand

Agree. We should definitively choose one, not having both.

First; i think it's ok for framework commands to rely on the framework application (getApplication()->getKernel()), it that's needed. After #23624 all framework commands rely on this. This PR creates a safeguard for that approach as currently we blindly assume this method exists.

Note kernel-aware and container-aware are semantically 2 different approaches for a command, currently we do both in the framework and ContainerAwareCommand wires both. With kernel aware you rely on the kernel container, not just any injected container (as implied by container aware).

Imo. it's good to be explicit, either be kernel aware (extend Command from this PR), or be container aware (implement ContainerAwareInterface or inject as a service yourself) but dont mix&match.

This PR creates a safeguard for that approach as currently we blindly assume this method exists.

Agree on the intent here, IDEs complain about it and we probably don't want to duplicate this instanceof check everywhere.
Technically there is a BC break here: currently these commands can work with any base Application subclass providing a Kernel getKernel(), so should we deprecate first?
I would remove the getContainer() shortcut also.

Last remaining concern: is it worth it at all? I think we need more opinions

Removed getContainer()

Last remaining concern: is it worth it at all? I think we need more opinions

I see a few options;

• this PR, update base class in 4.0 where needed
• add safeguards (instanceof) where needed
• favor kernel injection and dont rely on Application to be a framework application
• dont do anything; it works by convention

Not worth it if you ask me.

Right. Lets leave it asis then 👍