The Micro PHP Manifesto's Missing Tenet

"You can import classes from namespaces but you can't import functions."<p>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.<p>EDIT - I can't find refs online - I'd read that in a recap of the issue in PHPArchitect about 2 years ago.<p>Awesome...<p>"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."<p>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.<p>I get your point, but java/ruby/node and other platforms with extensive third party library ecosystems can quickly become dependency nightmares.

The problem is that PHP is going through growing pains a 15+ year old language should have fixed years ago, but didn't.<p>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.

The author nails it down. I have been doing functional PHP for many years now. I rarely need objects or classes. I don't like the direction where PHP is heading. Namespaces were nice, anonymous functions were nice, and short array syntax is nice. But I would like to see named parameters, function imports, namespaced constants, function overloading, more extensions, and JIT compilation (Facebook has already done the ground work). But I feel the interest with PHP core developers is to clone Java or .NET. It doesn't feel right to have huge PHP class libraries like Zend, Symfony, or Doctrine. PHP is glue! It's about hacking things nicely together. It's not enteprise stuff. Clean and simple.

For this item:<p>"PHP needs a modern package manager"<p>Is Packagist (<a href="http://packagist.org/" rel="nofollow">http://packagist.org/</a>) going to fill this need?<p>If not, what is missing? Bigger community? Easier integration? Time?

"Allow functions to be imported like classes"<p>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 <i>really</i> 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.<p>Anyway, if you really want to import functions it's not like it's impossible.<p><pre><code> echo "&#60;?php function myFunk(){ echo 'hi'; }" &#62; lib/myFunk.php </code></pre> Then `require 'lib/myFunk.php';` I'm sure there are more graceful ways in other languages but this works. (EDIT: Namespaces notwithstanding ;)

PEAR has had a lot of issues, but recently the PEAR community is addressing them. For instance you do NOT have to deal with the PEAR process if you want to use PEAR to distribute your code. You may setup your own channel* and do whatever you please. Secondly PEAR is in the process of setting up it's packages at Github to make it a lot easier to collaborate on code.<p>I think these changes are great and PEAR's future is looking a lot brighter due to the people driving these changes.<p>*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.

I started using functions widely in an MVc framework. It began when Rails was released, and I thought, how could I copy the "helper" mechanism in a way that makes sense for PHP?<p>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.<p>I write code like this...<p># file: helpers/say_hello.php<p><pre><code> function say_hello ($params) { $to = $params['to'] ?: $params; return "Hello, {$to}!"; } </code></pre> Which is auto loaded by the framework and usable like this:<p>(PHP):<p><pre><code> echo say_hello('World'); </code></pre> (Smarty):<p><pre><code> {say_hello to="World"}</code></pre>

I think NPM is at the opposite end of the spectrum to PEAR. Just try figuring out what the standard Mongo or MySQL library is with NPM. I think there needs to be <i>some</i> level of curation and/or tiering of packages.

This is a great point. I find PHP's movement towards things like PSR-0 just too verbose most of the time. There's a lot of plain function use in my work these days building a simpler/minimalist modern MVC framework (<a href="http://www.elefantcms.com" rel="nofollow">http://www.elefantcms.com</a>), and despite naysaying from the OOPS camp, it works very well in practice.

I'd disagree with the exclusive focus on functions. He's right though, about having better "loader" mechanisms.<p>You can write simple and concise OO code in PHP without writing Java-inspired superverbose code.

It sounds to me like the author is trying to write php like he would use javascript.<p>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.<p>Why not just use javascript?