"You can import classes from namespaces but you can't import functions."
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.
> 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.
Node.js and npm made a pretty vicious, backwards compatibility breaking change in its symbol loading algorithm in the move from 0.3 to 0.4. It was a weird and frustrating blip for those who were programming for node before that. What they now do with dependency management is pretty genius, since 0.4. Dependencies are installed locally to the package that depends on it, not globally on your system, and can be fulfilled recursively. Say you depend on Package B.1 and A.2, B.1 can simultaneously depend on A.1 and everything works out fine. It's perhaps the most interesting approach to the dependency problem I've seen (and, unfortunately, a system that couldn't be replicated in PHP without really shaking the foundation). (edits)
I don't doubt it's gotten better, but it's a bit of a case of 'once bitten twice shy' with me. I may come back at some point, but I've no pressing need atm to be playing with node.
I remember using CPAN for the first time and thinking it was magical. Like how they tell me the iPad is magical. Then a few years later using PEAR I suddenly felt the complete opposite.
I won't claim to know what the best alternative would look like, but I'd definitely take npm over PEAR any day.
I don't think PEAR caught on as well because PHP has been largely associated with cheap hosting services that didn't really give you access to a console that would let you use PEAR to it's full extent. Then you have to add in the fact that PHP doesn't really have a solid package management philosophy in the first place.
I think it has more to do with the usual background of each language's programmers. Perl coders (especially Back In The Day) tended to disproportionately come to Perl from systems administration backgrounds; package management is something that sysadmins are used to worrying about, so they created a strong culture of package management in Perl early on. PHPers on the other hand tend disproportionally to come from web design/HTML+CSS backgrounds, which haven't exposed them to the problems that a good package manager is designed to solve. So package management in PHP has never been a priority.
The long lack of namespacing probably hurt the adopting of package management in PHP but also it seems like overkill. I use an occasional PEAR package, but I always just download the source and integrate it into the project that way. It seems like more work to go through a package manager especially since I work on multiple different operating systems. It might also help that PHP packages tend to have very few dependencies.
I think it may seem like more work, but without strong package management things like reinventing the kitchen sink & copy pasta from various unreliable sources becomes the norm. You could almost say that the comments in the PHP manual were relied on more often than PEAR.
Although package management can cause it's own problems like dependency hell or multiple packages that do the same thing but none of them do it well.
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.
Comments
"You can import classes from namespaces but you can't import functions."
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.
> 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.
There is Packagist/Composer: http://packagist.org/
Node.js and npm made a pretty vicious, backwards compatibility breaking change in its symbol loading algorithm in the move from 0.3 to 0.4. It was a weird and frustrating blip for those who were programming for node before that. What they now do with dependency management is pretty genius, since 0.4. Dependencies are installed locally to the package that depends on it, not globally on your system, and can be fulfilled recursively. Say you depend on Package B.1 and A.2, B.1 can simultaneously depend on A.1 and everything works out fine. It's perhaps the most interesting approach to the dependency problem I've seen (and, unfortunately, a system that couldn't be replicated in PHP without really shaking the foundation). (edits)
I don't doubt it's gotten better, but it's a bit of a case of 'once bitten twice shy' with me. I may come back at some point, but I've no pressing need atm to be playing with node.
It's definitely bloody on the bleeding edge :)
Here's a link to the node_modules loading algorithm since v0.4, if you haven't checked it out, it's worth the quick read: http://nodejs.org/docs/latest/api/modules.html#loading_from_...
This module loading algorithm is what opens the door for npm to install nested dependencies in recursive node_modules subdirectories.
I remember using CPAN for the first time and thinking it was magical. Like how they tell me the iPad is magical. Then a few years later using PEAR I suddenly felt the complete opposite.
I won't claim to know what the best alternative would look like, but I'd definitely take npm over PEAR any day.
I don't think PEAR caught on as well because PHP has been largely associated with cheap hosting services that didn't really give you access to a console that would let you use PEAR to it's full extent. Then you have to add in the fact that PHP doesn't really have a solid package management philosophy in the first place.
I think it has more to do with the usual background of each language's programmers. Perl coders (especially Back In The Day) tended to disproportionately come to Perl from systems administration backgrounds; package management is something that sysadmins are used to worrying about, so they created a strong culture of package management in Perl early on. PHPers on the other hand tend disproportionally to come from web design/HTML+CSS backgrounds, which haven't exposed them to the problems that a good package manager is designed to solve. So package management in PHP has never been a priority.
The long lack of namespacing probably hurt the adopting of package management in PHP but also it seems like overkill. I use an occasional PEAR package, but I always just download the source and integrate it into the project that way. It seems like more work to go through a package manager especially since I work on multiple different operating systems. It might also help that PHP packages tend to have very few dependencies.
I think it may seem like more work, but without strong package management things like reinventing the kitchen sink & copy pasta from various unreliable sources becomes the norm. You could almost say that the comments in the PHP manual were relied on more often than PEAR.
Although package management can cause it's own problems like dependency hell or multiple packages that do the same thing but none of them do it well.
PEAR's got a number of problems.
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.