Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inconsistencies in factory parameter resolution #431

Closed
predakanga opened this issue Jul 15, 2016 · 2 comments
Closed

Inconsistencies in factory parameter resolution #431

predakanga opened this issue Jul 15, 2016 · 2 comments
Labels
bug
Milestone

Comments

@predakanga
Copy link
Contributor

@predakanga predakanga commented Jul 15, 2016

Thanks for merging the PR on #362, but unfortunately I've just discovered a couple of bugs that it creates/reveals.

There are two big issues:

  1. If a type-hinted factory parameter is resolvable from the container, any supplied parameter will be ignored

    This is an easy fix - just need to bump AssociativeArrayResolver to the top of the ResolverChain in FactoryResolver.php

  2. FactoryParameterResolver overwrites already resolved parameters

    Again, a simple fix - just needs this preamble added (taken from other resolvers in php-di/invoker):

      $parameters = $reflection->getParameters();
    
      // Skip parameters already resolved
      if (! empty($resolvedParameters)) {
          $parameters = array_diff_key($parameters, $resolvedParameters);
      }
    

I'm happy to prepare a PR to fix these (or just provide tests for reproduction), but wanted your input: FactoryParameterResolver could be replaced with a combination of TypeHintResolver and TypeHintContainerResolver. Would you prefer a fix to FactoryParameterResolver, or removing it in favour of the two TypeHint resolvers?

@mnapoli
Copy link
Member

@mnapoli mnapoli commented Jul 15, 2016

FactoryParameterResolver could be replaced with a combination of TypeHintResolver and TypeHintContainerResolver

I reimplemented a dedicated resolver for performance reasons (see #347): the duplicated code was really nothing and factories are heavily used so it made a difference. Right now I haven't tested performances yet (will do before the stable release) but it's possible I end up "merging" AssociativeArrayResolver into FactoryParameterResolver for the same reasons. So I would suggest to keep FactoryParameterResolver as it is for now (and add the fix into it).

Thanks!

@mnapoli mnapoli added the bug label Jul 15, 2016
@mnapoli mnapoli added this to the 5.4 milestone Jul 15, 2016
@predakanga
Copy link
Contributor Author

@predakanga predakanga commented Jul 15, 2016

Good to know - I've added a note to the phpdoc for that class, so that people know the logic behind it.

PR incoming!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.