🌐 AI搜索 & 代理 主页
Skip to content

Conversation

@DaumantasUrb
Copy link

  • Use TypeFactory::class() instead of fromString() for proper instance types
  • Return null instead of object|null when service is not found
  • Allow custom type resolvers to fully override inferred types

This improves type inference accuracy for Symfony DI container get() method by ensuring services return proper reflected class types instead of generic class-string types.

- Use TypeFactory::class() instead of fromString() for proper instance types
- Return null instead of object|null when service is not found
- Allow custom type resolvers to fully override inferred types

This improves type inference accuracy for Symfony DI container get() method
by ensuring services return proper reflected class types instead of generic
class-string types.
if (empty($id) || empty($class)) {
return null;
}
// Use TypeFactory::class() to create an instance type
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

redundant comment ...

@dantleech
Copy link
Collaborator

dantleech commented Nov 10, 2025

This looks ok... but it's not clear to me what the problem was? in what way(s) is this an improvement? what concrete benefits are there?

@DaumantasUrb
Copy link
Author

This looks ok... but it's not clear to me what the problem was? in what way(s) is this an improvement? what concrete benefits are there?

for symfony container - string literals, without phpdoc
nvim-coc + phpactor maybe for other setups too.

//no typehint
$config = $this->container->get('config');

Previous:

Screenshot 2025-11-11 at 10 30 30

Updated:

Screenshot 2025-11-11 at 10 31 39

@DaumantasUrb
Copy link
Author

ill make a cleaner pr

@DaumantasUrb DaumantasUrb marked this pull request as draft November 11, 2025 09:28
@dantleech
Copy link
Collaborator

dantleech commented Nov 11, 2025

hm, indeed I see! the only potential issue is erasing the original type information (?object) if the service cannot be resolved - as that doesn't necessarily mean the service doesn't exist as the XMLcould be invalid, but equally it's not entire clear that the approach here is wrong as the result is pratically useless anyway in this case.

it would be nice if the tests were updated to account for the bad behavior, but perhaps it's not that easy

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants