-
Notifications
You must be signed in to change notification settings - Fork 11k
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
[5.4] Make with #18271
[5.4] Make with #18271
Conversation
All my tests pass now. If anyone sees any broken behavior it with it feel free to let me know so I can add a test. |
@@ -710,7 +710,7 @@ public function build($concrete) | |||
// hand back the results of the functions, which allows functions to be | |||
// used as resolvers for more fine-tuned resolution of these objects. | |||
if ($concrete instanceof Closure) { | |||
return $concrete($this, last($this->with) ?: []); | |||
return $concrete($this, last($this->with)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using last
here means that the composer.json needs to be updated to include illuminate/support
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK I will remove those calls.
I should note this makes a change to the old behavior of the |
Hey Taylor, thanks for this. I know you mentioned that back and forth on this is not helping and I do agree. I have a small problem with this PR. The This would solve a lot of community issues up front without code changes (unless already running on 5.4), and implement the methods you need for PSR-11 compatibility in the future? |
Make can not have same signature as makeWith on 5.4 because we don't make breaking changes on point releases. Adding that parameter would break the interface. I personally am totally apathetic towards PSR-11 as I think it's fairly useless overall but since it is so simple to add I don't have a huge problem with adding compatibility for it in Laravel 5.5. |
Haha, and here I was, wrongly assuming that this was all gearing the container up for PSR-11. Thanks for clearing that up. I'm sure it'd be BC if the signature became Either way, nit picking and I'm grateful you've put this PR together. |
No, it wouldn't be backwards compatible. Look at the container interface. |
It wouldn't break the interface if |
Changing an existing public signature to add an optional param is a break. Might not affect many, but still a break. |
How would it affect them ? Even in the hypothesis some users were extending the base container without the optional parameter, it would still pass : interface ContainerInterface {
public function make($abstract);
}
class Container implements ContainerInterface {
public function make($abstract, $parameters = null)
{
// works
}
}
class ExtendedContainer extends Container {
public function make($abstract)
{
// works as well
}
} |
@RemiCollin Actually looking at it, Taylor is absolutely correct when he says look at the interface for the container. Adding the extra parameter to the interface would not play well with any extended container instances that do not currently add an optional parameter. Alas, this is what it is. Looking forward to this PR being merged. |
Yes, if you change the Mostly wanted to showcase how it would be possible to maintain pre-5.4 compatibility, while not introducing BC in current release. Not saying it would be a good pratice or not, it's totally debatable, but I think that any tool/language feature we have to provide users with smoother upgrades should be considered. |
People, I'm not going to argue if it is a breaking change or not. It obviously is if you understand how PHP works. Please no more discussion on that topic. |
Do people even want this feature or not? People were freaking out about wanting in the issue thread and now its just a couple of people arguing about BC. I'm not going to bother with it (because I think the feature is kinda silly) if this isn't actually a needed feature. |
Not arguing, just discussing implementation. But you're right, I won't bother if you feel it's an inappropriate discussion to have on a PR. |
@taylorotwell Gosh the communitys wants and needs have really ground you down man. No arguments to be had here, just, I hope, constructive conversation. The community does absolutely want this, I'm not sure why no one else has chimed in and given a thumbs up but I speak for many people on my team who would very much like this functionality back. |
…meters (#18320) Following: laravel/framework#18271
@taylorotwell With this it is impossible to pass a scalar in params :( |
@taylorotwell Thanks for the feature, but I wasted my 2 hours for finding this change. I think you should mention this method |
I didn't know I wanted this feature until about 1 hour ago. Has make it so much easier to pass different configs into generating Guzzle clients now depending on if I'm testing/debugging/in production. So thank you! |
It saved my time too. Thanks! |
Thank you, thank you for this re-addition! |
Hi all, I'm having an issue with testing/mocking/replacing the bind in the container. Let me try to explain.
This is the implementation:
Everything working nicely in other tests but when I try to replace that class, it doesn't hit the replacement:
It never hits "IT HIT" :( Do you know if there is any problem/issue with binding and resolving with Thank you so much. |
this is not the appropriate place to ask for debugging help. Please ask in the Slack or on a forum (stackoverflow or others). Thanks |
This allows functionality similar to old
$container->make(class, params)
functionality.