Conversation
|
why not |
|
@hrach Because that's evil. |
|
@JanTvrdik evil is the response which does not state any real arguments. |
|
"Evil" does not mean anything, but I also dislike findByType in this case. On Tuesday, 27 September 2016, Jan Škrášek notifications@github.com wrote:
Ondřej Mirtes |
|
What is added value of tag in DI over implemented interface? |
| /** @var \Nette\DI\Container */ | ||
| private $container; | ||
|
|
||
| public function __construct(\Nette\DI\Container $container) |
There was a problem hiding this comment.
This duplicates tag and DI logic and violates few SOLID principles. No need for that.
Rather use Extension and beforeCompile() method:
class PhpStanExtension extends CompilerExtension
{
public function beforeCompile()
{
$containerBuilder = $this->getContainerBuilder();
$registryDefinition = $containerBuilder->getDefinition($containerBuilder->getByType(Registry::class);
// or findByTag(), whatever you prefer
foreach ($containerBuilder->findByType(Rule::class) as $definitionName => $definition) {
$registryDefinition->addSetup('register', ['@' . $definitionName]);
}
}
}| } | ||
| } | ||
|
|
||
| private function register(Rule $rule) |
There was a problem hiding this comment.
More ways to adjust class behavior usually leads to more bugs.
I'd recommend using one and adding another WHEN really needed.
|
@ondrejmirtes yep, this is an argument! Though, doing this with factory, which dependes on the DI, imo not a nice solution. |
|
Please stop this bikeshedding, it's really not important 😊 I don't want a compiler extension because I want to get rid of the Nette On Tuesday, 27 September 2016, Jan Škrášek notifications@github.com wrote:
Ondřej Mirtes |
|
What is bikeshedding? You don't want to use Nette\DI or and DI component? In second case, you are starting creating own DI. Just wonder, what are your reasons (apart feelings) to not to use Nette or any DI? |
|
Obsessing over some minor detail where the value of the whole thing is completely unrelated :) See https://en.wikipedia.org/wiki/Law_of_triviality. I expect the neon service config completely gone by 0.5 or 0.6, so I don't want to discuss something that is not there for the long term and therefore doesn't matter. For anyone interested, this is the current roadmap for 0.2: https://trello.com/b/r9mZ7SZ0/phpstan But please, if you want to implement a feature, first discuss it with me before sending a PR, I have some ideas about how the codebase should evolve. |
|
I see. We didn't know you don't want to use Nette DI nor Neon. This explains a lot from your messages :) I didn't find answer for my last question.
"Don't want to explain" is also an answer. |
|
I think that having a separate DI container is not a very good idea, no similar tool I know does that. I included it for current versions because it helped to speed up the development until I have a better idea how to approach this problem of creating my own objects. One way to do this is to have a naked phpstan-core and phpstan-nette/phpstan-symfony bridges with its own container extensions. That would also allow to share services between the analyzed app and PHPStan class reflection extensions which is sometimes needed and currently solvable only by copy-pasting configuration. |
|
That convention might be as same as were static to DI. Nobody used DI, because everybody used static. Tradition is not always good reason to do something. I use DI for similar tools and I don't see any disadvantages. That's why I asked.
I look forward to this, if you are really determined and will come with something better than DI container. |
|
Merged as 45eed0f (build was failing due to a dep conflict which I solved earlier today in masterú. Thanks! |
Věci k vyřešení:
$tagToServicesamostatnou static helper třídu?NetteContainerHelpers? Případně udělat vlastní bridge na nette container (v budoucnu jen switchneš na symfony)?registerv registru? Za mě ano, ale je to bc breakDefinedVariableInAnonymousFunctionUseRule. Nevím, jestli to byla chyba nebo záměr