IIRC one of the arguments for the \ namespace separator was that it would allow for namespacing functions. Someone (perhaps a few people) had demonstrated a :: separator namespace patch, but it would only work with classes, and it was felt that \ was the only legitimate option because it would allow namespacing of non-class code.
EDIT - I can't find refs online - I'd read that in a recap of the issue in PHPArchitect about 2 years ago.
Awesome...
"PEAR has been around since before PHP5's release in 2004 and there are 179 modules hosted at pear.php.net for 5.0+. (And only 19 for poor PEAR2 and PHP 5.3) Contrast with npm which has been around since August 2010 and hosts 6,157 packages."
I'm no fan of PEAR, but when people start showing off how many XYZ something else has, I always have to wonder if it's because the default/core/base platform doesn't provide much out of the box. And... hey - downloadable packaged code is fine and all that, but you run the risk of version hell pretty quickly. npm is, imo, already hitting that - more than 6 months ago all I wanted to do was download node and run vows and zombie. No dice - I lost count of the errors I hit trying to make that work because of some version incompatibilities.
I get your point, but java/ruby/node and other platforms with extensive third party library ecosystems can quickly become dependency nightmares.
Actually, what I found sorely missing in php and started loving in the ruby world is bundler. It's not a package manager, but a dependency manager. You feed it a list of gems that you directly depend on and it figures out which gems to install in which versions so that all direct and indirect dependencies are satisfied. If it can't, it prints a meaningful error message. On top of that you can stack tools like gemnasium which track which of your dependencies were updated.
I do have a couple of projects that depend on about a hundred different gems. Managing that would be impossible without bundler. On the other hand, having a tool that enables you to manage this complexity makes you write smaller and smaller self-contained, separately testable gems that just add some little piece of functionality on top of some other lib or pulls together multiple libs and adds the glue code. It's actually common that even full-stack frameworks like rails or padrino consist of a handfull of separate pieces with another gem gluing them together. Even ORMs such as datamapper come in pieces.
I know of no tool in the php world that even attempts to solve this problem.
I won't claim to know what the best alternative would look like, but I'd definitely take npm over PEAR any day.
The PEAR maintainers seem to disagree with the direction PHP is going as a language, so they don't keep it up to date with changes in the language. If you want to use PEAR, you need to either hack the code yourself (why use PEAR) or you need to put PHP in an out-of-date compatibility mode.
"PHP needs a modern package manager"
Is Packagist (http://packagist.org/) going to fill this need?
If not, what is missing? Bigger community? Easier integration? Time?
PHP CMSes had package managers for years. It wouldn't hurt to look at them and learn what they did right and wrong before cloning Ruby/CPAN/NPM solutions.
It's not as "structured" as methods in a class that extends a Controller class, but it works just as well and eliminates a good bit of boilerplate code in the process. Also helps new developers get up to speed quickly I've found.
Now there's too much atrocious code out there that would break with updates to PHP. I firmly believe PHP.next has to declare it's going to break everything, take all that we've learned now, and build a great web language that is easy to use.
I do agree that along with package management there should be a strong community/social component involved that critiques & communicates about packages available.
I think these changes are great and PEAR's future is looking a lot brighter due to the people driving these changes.
*Personally I think it's a good idea to have some kind of vetting process in place. If you look at for instance the WordPress plugin repository as an example of a repository without it you'll notice loads of crappy plugins or abandoned code. I presume that with a vetting process (and maintainer process) one could prevent this from happening.
Moving to Github is a good move. Opening up some sort of "PEAR commons" where the requirements aren't as arduous as PEAR proper would go a long way.
When package dependencies are tracked explicitly there's a very natural, Page-rank like effect that pushes the best, most reliable packages to the forefront because everyone depends on them. Just look at npm's "most depended on" list: http://search.npmjs.org/ You can look at any package and see what other packages depend on it.
PEAR's curation process feels a lot like Yahoo's of old's curated link database. npm's feels a lot like Google's "anyone can publish, we'll track dependencies, the good stuff will surface".
My answer was to use plain functions as helpers, at first because they could easily become Smarty modifiers, and later realized the function-only pattern worked really well across the whole app.
I write code like this...
# file: helpers/say_hello.php
function say_hello ($params)
{
$to = $params['to'] ?: $params;
return "Hello, {$to}!";
}
(PHP):
echo say_hello('World');
{say_hello to="World"}existing php projects won't soon benefit from language features and new frameworks without significant rewrites, and their absence make php less attractive for the style of development he seems to favor.
Why not just use javascript?
I'm a micro-php sympathizer, but I'm wondering if the pendulum isn't swinging a little too far in the other direction here. Import libraries function by function? Are there really no libraries that are small and address your needs with a minimum of cruft? If we don't want to import a simple router class, maybe the solution is to trim down the class, not break it up into discrete functions to be imported one by one. What would a more-than-small application look like like this? I fear it'd look crazy; but I'm just speculating.
Anyway, if you really want to import functions it's not like it's impossible.
echo "<?php function myFunk(){ echo 'hi'; }" > lib/myFunk.php
You can write simple and concise OO code in PHP without writing Java-inspired superverbose code.