Show HN: PHP Code Generator – A scaffolding framework
about.asika.tw
about.asika.tw
This seems like the worst of all worlds.
It isn't though. PHP is many things but overly verbose isn't one of them * . Although there does seem to be a drive by some developers to make PHP look and act as much like Java as possible. Maybe this comes from discomfort at PHP not being structured or strict enough out of the box for their liking. If you've only ever dealt with well-engineered languages which have a certain, coherent set of patterns and paradigms baked in, and which demand you write your code a certain way, and you approach PHP, you're going to have a problem.
I don't know why a tool like this would be useful, but it wouldn't be because of the language. PHP exposes its own token parser - you can generate PHP code with much less abstraction than this.
*classes like IteratorIterator aside...
Competition between frameworks and libraries ensures that there are multiple solutions to meet multiple needs, and also that consensus, where it exists, exists due to the popularity of a package, not the dictate of someone setting an arbitrary "standard" for the community. You can guarantee that Laravel is going to be updated because people use it and contribute to it, not because it's the only option.
And there's no guarantee that a single solution is going to keep backwards-compatibility. That is always entirely at the whim of the developer. Removing room to innovate only guarantees stagnation, it doesn't guarantee the standard.
92 pages of the same basic router implementation. That is a problem. A huge problem.
Also, to be fair to your argument, Composer will load packages from outside Packagist, and VCS systems other than git, so the actual universe of available routers is probably much, much bigger. I'd suggest this as another example of how not conforming to a standard (Packagist as the de facto PHP repository) is a benefit. You don't even have to care about Packagist and Composer still works just fine.
Composer makes dependencies flat , and PHP isn't module based,but namespace and class based.
Which makes libraries way more stable,unlike the nodejs galaxy of packages for instance.
And by the way,most of the packages listed aren't routers.
If you only search the word "router",you'll get only 21 pages,roughly 300 packages.
now go on npm.org and type in router you'll get more than 1600 packages.
Where do you think the problem is ? is nodejs a module based language with dependency trees , or PHP , class and namespace based language with flat dependencies?
(Also, note that the problem is more with Packagist's search results, since most of them aren't even routing libraries)
Standardised, framework agnostic, go-to packages that are the de-facto solutions for specific problems
You don't need to download the entire Symfony framework
It does tie you into the Symfony Request object, but otherwise there are no other dependencies.
People work on what interests them when it comes to open source. Besides, most of what you're describing is already being worked on (and naturally, being disparaged as unnecessary or a poor solution by plenty of commentators on HN).
By the way, your entire comment can be applied to just about every single project that's posted to HN. To the point of irrelevance.
This framework would not solve a single problem I have had. None of the frameworks do, which is why I'm not using one of them. The only thing I really found lacking in core PHP was a way to manage the urls. (In this case, query strings.) I believe this would have been difficult on any platform, as the data is deeply hierarchical so the urls would be gnarly no matter what. So I wrote a class that understands the entity hierarchy and can generate query string sets that are needed for each level in the scope.
I wish the PHP community would spend less effort trying to be rails and more effort on simply removing pain points of basic, idiomatic PHP development.