So now we have PHP, which started as a lightweight script language, following Java down the road toward a more verbose style, and so now we need code templates? Java programmers have been doing this for awhile, they rely on IDEs such as Eclipse or IntelliJ to write some of the boilerplate for them, and that is important in a language like Java, which has so much boilerplate. But with Java, that boilerplate at least buys you something: static typing and type checks, which allows the compiler to check for bugs, and which offers immense benefits in terms of speed. In PHP, we get... what? Apparently PHP is now verbose enough that people feel the need to write code templates for it, but what benefit do we get in exchange for all of that boilerplate? PHP is still dynamic, and it is still very slow.
>Apparently PHP is now verbose enough that people feel the need to write code templates for it
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.
PHP has a real glut of talented programmers right now, which is why you're seeing the same overengineering that plagues Java. Fun problems have dozens of solutions because everyone wants to work on them. Templating is just one of those. Weird, case-specific conventions are another.
This isn't really anything new. Yii and Symfony have been doing code generation for years. Someone simply decided to create a library that's not framework specific.
The problem is that everyone is creating every library, over and over. It is a real problem in PHP that there is no single, polished solution and every framework is being reinvented (and breaking BC) constantly.
Or go work on original problems that have not already been solved dozens of times. Projects like this are a waste of talent. There are clearly some smart programmers writing libraries for PHP. The question is, why do they keep writing the same stuff, over and over? All of humanity would benefit if some of these smart people focused on doing something domain specific (medicine, law, education) or dove deeper and helped re-invent the stack at a deeper level. Maybe re-invent PHP as a language that has primitives for concurrency. Or leave PHP and work on other problems that plague the tech industry (the obsoleteness of HTTP/HTML as a way of delivering documents, when people increasingly want software over TCP, not documents).
I suspect you are ascribing way too much credit to a code generation library.
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.
Right, but that's a large, core Symfony component, not a small library. It essentially dictates how you handle fundamental tasks (such as routing) and immediately starts you off doing things the "Symfony way".
Eh, it doesn't dictate how you handle routing. I think you're misunderstanding the dependency here: what StackPHP depends on is the HttpKernel interface. Basically the function signature for a HTTP request handler.
It does tie you into the Symfony Request object, but otherwise there are no other dependencies.
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.
No it isn't, it's the way open source is supposed to work. There being 92 pages of routers doesn't stop anyone from picking the most popular and well-maintained one. Almost anyone who actually cares is going to pick one of the large frameworks (which probably use Symfony) or use nikic's FastRoute. If you're worried about small packages being maintained into the future, that's what forking is for. If you want to write your own, you can.
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?
I have been writing an application that is a thin PHP application on top of a relational model that implements (what I hope is) a clever business.
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.
27 comments
[ 3.8 ms ] story [ 68.5 ms ] threadhttps://minuteproject.wikispaces.com/Php+doctrine
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...
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.
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.
Standardised, framework agnostic, go-to packages that are the de-facto solutions for specific problems
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, note that the problem is more with Packagist's search results, since most of them aren't even routing libraries)
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?
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.