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

Override callback resolver #10

Merged
merged 11 commits into from
Feb 4, 2016
Merged

Conversation

praswicaksono
Copy link
Contributor

this PR will solve issue #9

@mnapoli
Copy link
Member

mnapoli commented Feb 3, 2016

Thank you for the PR! Could you also add a functional test in this class to cover the behavior you described in #9? i.e. that something like this works:

$app->get('/{name}', HelloName::class)
    ->convert('req', HelloNameConverter::class);

I have a few other comments that I'll write inline the diff.


/**
* Class CallbackResolver
* @package DI\Bridge\Silex
Copy link
Member

Choose a reason for hiding this comment

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

No need for the @package annotation which is covered by the PHP namespace. Also could you update the description to explain why this class exists? e.g. This alternative resolver uses the generic Invoker to support PHP-DI's extended callable syntax

@mnapoli
Copy link
Member

mnapoli commented Feb 3, 2016

I don't have much time right now to check, do you know if the callback_resolver service is used elsewhere in Silex (other than for param converters)? I'm asking that because I'm wondering:

  • could this change add support for "PHP-DI callables" on other features of Silex (which would be great)?
  • but could this change also break/change the behavior of something else?

Anyway I'm looking forward to merge and release this!

@praswicaksono
Copy link
Contributor Author

Silex use callback_resolver on MiddlewareListener, ExceptionListener, ConverterListener and ViewListener so PHP-DI Callable will useful on those feature too. I don't think this will break them or other feature but anyway I will add functional test to all those feature.

@mnapoli
Copy link
Member

mnapoli commented Feb 3, 2016

👍 awesome

@praswicaksono
Copy link
Contributor Author

ready for review :)

$this['callback_resolver'] = $this->share(function () {
return new CallbackResolver(
$this,
new CallableResolver($this->containerInteropProxy)
Copy link
Collaborator

Choose a reason for hiding this comment

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

Could the callable resolver from line 54 be reused here? I don't think there's a need to create it twice.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yep, sure should I register callable resolver in DI first?

Copy link
Member

Choose a reason for hiding this comment

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

should I register callable resolver in DI first?

yep sounds good. Maybe name it something like phpdi.callable_resolver to avoid crowding the root "namespace" for users?

@jdreesen
Copy link
Collaborator

jdreesen commented Feb 3, 2016

I'm going to take a deeper look when I'm at home this evening.


/**
* @param string|callable $name
* @return callable
Copy link
Collaborator

Choose a reason for hiding this comment

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

Don't know whats the convention for return type hints for callables but it should be consistent with convertCallback(), I think.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

convertCallback always return callable whatever its form, but the old API only hinted as a callable array. Since we use PHPDI callable resolver return type is not limited to callable array, so I hinted callable as return type.

@jdreesen
Copy link
Collaborator

jdreesen commented Feb 3, 2016

Some small nits and style consistency thingies. Otherwise it's fine, I think :)

// return immediately if $name is callable
if (is_callable($name)) {
return $name;
}
Copy link
Member

Choose a reason for hiding this comment

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

I'm afraid this might be an issue as method calls are considered as statically callable. For example ['Logger', 'warning'] is considered callable by PHP even though it's not a static method, so calling Logger::warning() would be wrong and the "correct" callable would be [$logger, 'warning']. Have a look at this line: https://github.com/PHP-DI/Invoker/blob/master/src/CallableResolver.php#L69

Anyway all that to say that this shortcut will create issues with some types of callables.

@mnapoli
Copy link
Member

mnapoli commented Feb 4, 2016

That was fast ;) That looks all good to me! @jdreesen?

@jdreesen
Copy link
Collaborator

jdreesen commented Feb 4, 2016

👍 from me :)

@mnapoli
Copy link
Member

mnapoli commented Feb 4, 2016

👍 thanks @Atriedes

mnapoli added a commit that referenced this pull request Feb 4, 2016
@mnapoli mnapoli merged commit 4c03fba into PHP-DI:master Feb 4, 2016
@mnapoli
Copy link
Member

mnapoli commented Feb 4, 2016

I'll create a release tonight with a documentation update

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

Successfully merging this pull request may close these issues.

3 participants