- Setup a library tracking system (composer, the autoload stuff)
- Setup basic Dependency Injection (using code in this case, but the same could be done through config files or annotations)
- Parse requests into a request class
- Setup a middleware chain, including a router, and dispatch a request through it
How is this different from flask/django (python), rails (ruby), or gin (golang)? I'd say the basic concepts are pretty much the same, except maybe the library handling part. In other words, I don't think there's enough "meat" in this example to appreciate actual relevant language differences.
Also, you can write "java-like, enterprisey" code (Symfony) that values explicitness over magic, or go the other way around following the "convention over configuration" mantra, and end up at Laravel that is much more Rails-like.
Finally, PHP is still has several advantages over java for many people out there:
- Every request starts from scratch, meaning it is impossible to accidentally provoke side-effects on other requests
- The package system (composer) is just a package management system, and hence MUCH simpler to understand than ant/maven/ivy, that are entire build systems that also want to control testing, deployment, and everything
- Development is faster-paced thanks to the lack of compilation. You can even easily setup an environment with auto-reloading and just "save updated code" -> "see result in less than a second".
- You can deploy your app to any of a horde of (cheap) hosting providers and let others deal with the ops side. The service may exist in java-land, but it certainly isn't as ubiquitous.
- PHP programmers are cheap (yes, cheaper than java-programmers).
On the other hand, things in PHP-land are improving at such a rapid pace (but without the churn of JavaScript) that if you are a PHP developer there isn't much reason to switch to something different but similar.
In a lot of fronts it means mimicking Java, but I think it still is more flexible (and less reliable as the other side of the coin). It’s still very easy to drop down to “quick and dirty” code anywhere it’s needed, and it still benefits from a very low bootstrap cost to deal with single command/requests.
Or would you propose sending a boolean to indicate null as well as a string in a data type?
https://www.lucidchart.com/techblog/2015/08/31/the-worst-mis...
String is not nullable String? Is nullable and the compiler/ide will force you to check for null when you use it.
Which, I agree, can be downsides as well.
I don't know that I've ever encountered something like:
RequestProcessorFactoryFactory.RequestProcessorFactory.getRequestProcessor(XmlRpcRequest)
There's inheritance, and there's overindulgence.