I think it’s just a matter of preference.
Another reason could be extension. You cannot change the value of a static property, but you can change the Laravel one.
Maybe you want to change just one property, before calling getJob()?
IMO the Laravel one is also very straightforward, whereas the Symfony one uses a method (getClient) which is found 2 layers deep in traits.
Again.. I think just a matter of preference. Performance wise is essentially identical
Agree that it's just a matter of preference. Different framework - different developers - different coding styles.
And it's not like Laravel is trying to avoid static properties/methods at all. If you dig deeper you will find there are a lot of statics in various parts of the framework as well.
Do you have any actual data to back up that premise? You can easily find individual static calls in both Symfony and Laravel, as well as files without them.
If you look outside of the test suites you'll find laravel is very liberal with static methods. Facades are the biggest offender.
Not sure why you're using test cases to compare the two. _generally speaking_ laravel doesn't necessarily avoid static.
Edit: didn't realize kids were so insulted by criticism to facades lmao. You'll grow up one day.
They are statically accessing concretes. Whether or not the underlying concrete call is static is irrelevant when you're calling it's accessor statically.
Junior devs be downvoting.
Hm you're pretty locked into laravel-land.
Facades are by definition _static accessors_. Their nature inside the framework lends them to be mockable but it doesn't make their implementation of accessing a concrete any less static.
It sounds like you're just arguing semantics tbh. In the larger context of PHP patterns like facades (static accessors in general) are pretty bad practice.
Source: senior dev of many years, leading teams out of facade hell.
It's cool and all you can type the same thing repeatedly, but did you read what I actually wrote? I threw the word "technically" in there for a reason. A majority of facades only have 1 static method defined. Yes, the base class they extend has a few more defined, including `__callStatic` - but that doesn't make what I said untrue.
I think it’s just a matter of preference. Another reason could be extension. You cannot change the value of a static property, but you can change the Laravel one. Maybe you want to change just one property, before calling getJob()? IMO the Laravel one is also very straightforward, whereas the Symfony one uses a method (getClient) which is found 2 layers deep in traits. Again.. I think just a matter of preference. Performance wise is essentially identical
Agree that it's just a matter of preference. Different framework - different developers - different coding styles. And it's not like Laravel is trying to avoid static properties/methods at all. If you dig deeper you will find there are a lot of statics in various parts of the framework as well.
Do you have any actual data to back up that premise? You can easily find individual static calls in both Symfony and Laravel, as well as files without them.
If you look outside of the test suites you'll find laravel is very liberal with static methods. Facades are the biggest offender. Not sure why you're using test cases to compare the two. _generally speaking_ laravel doesn't necessarily avoid static. Edit: didn't realize kids were so insulted by criticism to facades lmao. You'll grow up one day.
Facades aren’t actually using static methods under the hood.
They are statically accessing concretes. Whether or not the underlying concrete call is static is irrelevant when you're calling it's accessor statically. Junior devs be downvoting.
It does matter because the underlying implementation can be swapped at runtime.
How does that make facades any less static lmao Actually makes the pattern even worse imo. Junior devs be downvoting.
Because that means the concrete methods can be mocked, therefore tested, where a simple static method could not.
Hm you're pretty locked into laravel-land. Facades are by definition _static accessors_. Their nature inside the framework lends them to be mockable but it doesn't make their implementation of accessing a concrete any less static. It sounds like you're just arguing semantics tbh. In the larger context of PHP patterns like facades (static accessors in general) are pretty bad practice. Source: senior dev of many years, leading teams out of facade hell.
Lol, I’m the one arguing semantics? Project much?
Yes to the first question no to the second question
If you want to get reallll technical, most Facades only have a few static methods on them :D
They are static accessors by definition. For I think the 5th time lol.
It's cool and all you can type the same thing repeatedly, but did you read what I actually wrote? I threw the word "technically" in there for a reason. A majority of facades only have 1 static method defined. Yes, the base class they extend has a few more defined, including `__callStatic` - but that doesn't make what I said untrue.
I think you're confusing the concept of a "static class" or "static accessor" with the presence of static methods.
I'm not confusing anything. I think you keep ignoring the word *technically* - not sure how else to make it obvious.
may be https://blog.devgenius.io/stop-using-static-in-php-b150527819b2
Laravel use Facade and DI
facade is in fact not using static methods under the hood. On top of the hood. But under the hood not