philsturgeon
People use PHP and a package manager is needed to stop people constantly rewriting the same PHP. That means a package manager is required (we have a good one now) and support is required to take it forward (hence this post).
When will people stop the "RUBY DID IT" mentality and learn to get on with what needs to be done?
1. Build stuff. 2. Sell stuff. 3. Learn to make stuff faster.
I use Ruby sometimes, it sure is a lovely language. That doesn't detract from the fact that PHP is still the most largely used web programming language around.
I do development work in, consult about, get paid to write about and sell commercial products using... PHP. It has the biggest potential market for me so it has the most potential customers, the most potential readers and the most potential work.
Besides, even if you personally decide to switch to Ruby the PHP community will still exist and still suffer the same problems. Those need to be fixed, no matter what.
Please do not detract from a single topic with a random "PHP v Ruby" thread. I'm not surprised but I am disappointed.
At some point you need to have more classes, and where do they come from? One team of developers cannot forever add in more and more classes, that would be ridiculous.
If they allow other people to add in other classes they have an ever expanding codebase. If they dont allow developers to add in other classes then you are back to the original problem: where do I find new classes that will work with my code.
By using a package management system you distribute the workload to people who need a class, and so make it. People who have a vested interest (client project, some web service they are making, whatever) are responsible for working on a set of classes that really benefit them, like a payment library that works with Recurly, Spreedly, whatever. That should be made buy one developer, and a second developer could add in a new driver - instead of building the whole damn thing from scratch.
That is the approach package managers take, and they are much more useful than a one-man-army trying to build all the libraries.
Again if Flourish meets your requirements then great, but it certainly doesn't meet all potential requirements of the whole PHP community, package managers can with the "use whats there, build what isn't" approach.
OAuth, Authentication, Twitter API interaction, ORM's and all that jazz. None of that fits into the core at all.
You say that if the core of PHP got better then we wouldn't need MVC frameworks? What about things like ASP MVC? PHP is a language. A framework is an architecture that allows websites to be built in a certain way.
Building Composer is not "splintering by building yet another package manager", it is building the package manager we never had. Barely anybody in the community uses PEAR (I have met one PEAR developer ever, and I meet a lot of PHP developers) and there are not other existing options that work.
Composer works, so the more packages can be made generic and reusable instead of just depending on one framework the better it is for the whole community. This is the only way to reduce splintered efforts.
That is all entirely beside the point of "Adding various new good features would be good". Of course it would, but I'm not talking about trying to make every PHP developer learn C and send a pull request. That is outside the scope of this article.
It has also failed to keep up with progress, for example: fDate is basically the same as the recent DateTime object in PHP, as are many other classes now.
Moving forwards it seems like PHP is making the right calls, but backwards compatibility is important to the project as PHP has more legacy code than any other web language. That doesn't mean it's dead, it just means they can't say "sod it, lets re-write everything overnight".
The point of this article is not "What languages should PHP copy to get better", I am talking about "What PHP developers can do today with the available tools to fix things for tomorrow".
PHP has everything it needs to move to a more package-based way of working, it just needs the community to take it up.
If Symfony are the only framework to use it then Packist is just going to be full of their code and not a lot else.
I was hosted on PHP Fog but just had to do a quick dash to Pagoda Box as their instance resizing doesn't happen quick enough.
It should be up now, might need a dscache flush. What a mess.
You have to worry about your application being compatible with the version installed on the server and all sorts of other madness. Through this incredibly simple system (which will shortly become more powerful with its own interface) we can basically just install a package into your application in the same way most people would normally download, unzip, etc.
php oil install foo
Then add it to git, push and you're all good. Otherwise you have to run around installing dependencies and all sorts of other junk.
Try asking a question in #rails. Chances are you won't even see anybody post for 3 days, and if they reply they'll call you a fking noob.
Remember though, that class won't be loaded unless you want it.
There are 4 main namespaces.
Fuel\Core Fuel\App Fuel\Tasks Fuel\Migrations
Then packages have their own namespace too.
These help code that could potentially have the same name exists and allows for easy extending of core classes.
Class Foo extends Fuel\Core\Foo.
Thanks to a cascading file system very similar to Kohamas this is all very simPlenand very quick.
The Zend_Style_Class equates to classes/Zend/style/class.php and could exist in core or app, or packages, etc.