What benefits of ArgumentMetadata class instead of passing ReflectionProperty? https://github.com/symfony/symfony/pull/11457/files#diff-e00e36af5c58d36a069a385025be4f34R22 looks better than your ArgumentIsRequest

Also #11457 wasn't merged because of lack of performance tests. Maybe you should add blackfire comparation before and after.

@Koc for the simple reason that it's reflection. When this PR is merged, I can add a cache warmer that calculates all this information already so no reflection would be required run-time (unless not in cache).

Additionally it also avoids PHP_VERSION_ID checks because types and variadic differs between 5.5, 5.6 and 7.0, see 6496e67#diff-4cbcb4a4736436b811aa3f5059ca46b1R19

@Koc how would I do that? I have to admit that I've never used blackfire yet. In terms of performance this might actually be slightly slower (minimally) until a cached variant has been added.

https://blackfire.io/docs/up-and-running/installation
http://blog.blackfire.io/profiles-public-sharing.html

Create simple app based on symfony-standard, create profile, replace symfony's version with your patched, create profile again and compare them.

@Koc alright, I will see if I can do that

@Koc I made an application that can be tested https://github.com/iltar/blackfire-symfony-18308

Sadly I cannot run blackfire here due to system permissions.

This is an interesting topic as we've been talking about doing this kind of changes for years now.

Having more flexibility looks good on paper but we need to keep complexity as low as possible (that's why I'm quite reluctant on adding interfaces and factories when not needed -- see my comments). Also, we need to keep good performance. This last point is probably the only blocker if any. Can you profile the old and the new code on a "typical Symfony app" (not an hello world one) to see if there is an impact and what kind if impact these changes have if any?

@fabpot I'll hook it up somewhere this week and check the performance. Ideally I'd also implement a cache for the benchmarks (because that's what this is all pre-work for).

I agree about the complexity, that's why I want to keep this as simple as possible. Here's a list of the classes/interfaces and what they are designed for:

• ArgumentResolver(Interface); This is from the previous PR, making it easier to implement your own variant (this PR). This also allows the LegacyArgumentResolver (currently in ControllerResolver) to be injected.
• ArgumentValueResolverInterface; This is what can actually be used on an application level for action arguments, think about: ParamConverter to inject the current user #327. Parameter converters are nice, but slow(er than when this is cached) due to their reflection. This involves less magic to implement and a clear trace for developers where it hooks in. It also avoids injecting objects in the Request object, scoping them more effectively.
• ArgumentMetadataInterface; As I have commented before, this is a nice way to use the following bullet point to return a cached variant if generating classes.
• ArgumentMetadataFactoryInterface; This allows multiple implementations to accommodate a cache layer. My idea is to decorate the real-time resolver, when the cached version does not exist, I can fall back to the real-time and still provide the same functionality. I think this interface should be marked with @internal but I'm not 100% sure, in case someone wants to provide their own layer (like never resolving due to performance?).

Regarding the cache implementation I want to open a new PR so it can focus on that specific subject as I'm inexperienced with caching.

Caching should indeed be part of another PR. Performance without caching should stay in the same range as the current performance. Adding a cache layer is adding another layer of complexity by itself and won't be implemented by everyone (think Silex for instance). That's why performance optimization without caching is very important.

But then again, without numbers, we cannot really reason about the proposed changes.

You've got a fair point there. In any case, I could rename the LegacyArgumentResolver to something else and make sure everyone can keep using that regarding performance.

@iltar thanks for working on this. Although I cannot provide specific details, I agree with Fabien and this looks a bit over engineered. The fact that adds +1,200 lines of code and removes just 111 might be an warning about this.

@fabpot here are the results of my real-world application with the code as-is in this PR.

@javiereguiluz a lot of those lines are actually test duplication to provide 100% BC and a lot of those lines are also comments because a lot of small files got added. If you look at executable lines of code excluding tests, the difference is a lot less.

I agree that it's a bit of complexity added, but it would solve a lot of other problems; Mainly DX wise. Right now it's a pain to customize this code and is highly dependent on the default implementation. With this PR (e.g.) Drupal could significantly reduce the complexity in their code if they want. It also means that they would not have to backport the current fix for the variadic functionality either.

It means that I could add the following code instead of a ParamConverter

    /**
     * {@inheritdoc}
     */
    public function supports(Request $request, ArgumentMetadataInterface $argument)
    {
        return $argument->getArgumentType() === MyUser::class;
    }

    /**
     * {@inheritdoc}
     */
    public function getValue(Request $request, ArgumentMetadataInterface $argument)
    {
        return $this->tokenStorage->getToken()->getUser();
    }

The initial overhead is a bit more, but a ParamConverter is conceptually wrong here and causes a lot more overhead as it uses reflection to determine the same information yet again. For Developers it will be easier

Conclusion: it's slower in this PR, not by much but it is slower. The difference with 0 parameters is minimal and gains ~initial time*N Arguments. I think the added DX and flexibility is worth the minimal overhead, especially when you can avoid some of the magic done by ParamConverters.

note that if this functionality is not desired in the core, I can always publish it myself if #18187 gets accepted

// code used in HttpKernel
$sw = new Stopwatch();
$sw->start('18308');
// controller arguments
for ($i = 0; $i < 1000; $i++) {
    $arguments = $this->argumentResolver->getArguments($request, $controller);
}
$event = $sw->stop('18308');
$class = explode('\\', get_class($controller[0]));
dump(end($class).': '.$event.'; arguments: '.count($arguments).', '.$i.' iteration(s); branch: feature/argument-resolver-extention-point');

1 iteration on getArguments (master)

1 iteration on getArguments (feature/argument-resolver-extention-point)

1000 iterations on getArguments (master)

1000 iterations on getArguments (feature/argument-resolver-extention-point)

Same as the above but changed the variadic priority to -150 (as it cannot have a default value and is a rare case)

@iltar having separated commits will certainly ease reviews, but once done you should squash mines, they are not relevant. Thank you ;)

Docs PR is made regarding the controller resolver / argument resolver, so that should be ready before 3.1 arrives. I will start working on writing something for the new extension point (otherwise it's pretty useless imo).

@fabpot I'm having doubts about the resolvers:

I would like to propose the following naming before this is merged:

While writing the docs I noticed it's still fairly inconsistent and a lot to write.

@iltar don't you think the _value_ part in argument_value_resolver.* is a bit redundant? What about:

the new names are indeed much more consistent. I also like @javiereguiluz shorter proposal. Up to you between the 2 new proposals.

I like that, less is more in this case. I was running into another DX issue; when showing the ArgumentResolver in the documentation, I always have to pass an array of 4 items which together mimic the 3.0 behaviour. If I were to make the argument of the value resolvers nullable, I could set those 4 resolvers by default in the constructor. Or is an empty array enough? This implies you cannot ever have no resolvers.

Okay, small update:

• The ArgumentResolver arguments were optional (don't know why, lost in rebase). I've made use of that and initialized the objects with the defaults that symfony is using now.
• The HttpKernel now gives a slightly different deprecation about a behavioral change in 4.0 (BC break)
• DX is improved for people who don't know anything about the inner workings of the ArgumentResolver, it now works out of the box with the current default behavior.

@fabpot I think it's ready to be merged, all tests are passing without issues and I think most edge-cases are covered now.

Apart from my comment about the default value resolvers, I'm 👍 to merge this PR.

Thank you @iltar.

🎉 Thanks @iltar !

Couldn't have finished it this polished without you guys, thanks!