Console Helpers support about console HOT 13 CLOSED

@enumag Thanks. We might support it. Good point. I'll implement it.

Any other thoughts/ideas? Please consider it as small as possible. ;-)

from console.

@enumag HelperSet is just another services locator. I'm strictly against it, because it leads you to write overcomplicated structures as in Kdyby.

What is the advantage over constructor injection?

from console.

@TomasVotruba Symfony commands are not really compatible with constructor injection because all of them are instantiated every time you use console - instead of only the one you need. If you know a solution, please share.

from console.

@enumag Why is that issue? I use is for years like that and never had a problem.

If so, it belongs to Symfony\Console repository, not anywhere else.

Do you prefer service locators then?

from console.

@TomasVotruba It is a problem because I don't want to create all the services any command might have a dependency on every time I run any of them. Sometimes I use commands as long-running processes and I want to reduce their memory usage - meaning it's better to instantiate only what is necessary for the given command. This is the same thing as with Presenters/Controllers - would you want to instantiate all of them for every http request? Me neither. But this of course means there is some sort of service locator in PresenterFactory/ControllerResolver - and that's ok with me.

The thing with service locator is that it is not necessarily bad nor fully replaceable by dependency injection. It just should be used carefully and mainly hidden in libraries, but not used in applications themselves. This is of course why you dislike console helper. And I agree with you, I don't like them either. The service locator would be far better to have in Symfony\Component\Console\Application to load commands, not in the commands themselves. The real issue here is that Symfony\Component\Console\Command\Command::configure() is not static and implement this would require hacks involving ReflectionClass::newInstanceWithoutConstructor().

from console.

@enumag Still, Symfony\Console issue. This is wrong level of abstraction to workaround this.

There are many similar issues:
https://github.com/symfony/symfony/issues?utf8=%E2%9C%93&q=resolve%20is%3Aopen%20label%3AConsole%20

I recommend you focusing your energy there. It might actually change something and make situation better for all Symfony\Console integrations.

from console.

@TomasVotruba Precisly. But since there is no better solution at the moment it is still needed.

I'm well aware of those issues but since they have been sitting there for years I consider it a waste of time. Solving it is too much of a BC break for Symfony.

from console.

@enumag I've discovered that some default helpers are already setup in Symfony\Application (https://github.com/symfony/console/blob/v3.2.8/Application.php#L84).

I've merged #4 just few minutes ago. Do you need anything more? I saw some Container and Presenter helpers in Kdyby. Do you need them too?

from console.

I think #4 is enough. Please don't pollute this package with Kdyby garbage.

from console.

@enumag Great. But, what about ContainerHelper or PresenterHelper, do you use them? In case of you do, do you want to create them for each project?

from console.

ContainerHelper is about the only way to use services in commands. Or do you know any other? PresenterHelper - no thanks.

from console.

@enumag Could we consider this issue as done?

9fe2639

I experiment with some ProxyCommands for lazy-loading. We'll see. :-)

from console.

Yeah, thanks!

from console.