

The Micro PHP Manifesto's Missing Tenet - KrisJordan
http://krisjordan.com/micro-php-manifesto

======
mgkimsal
"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.

~~~
Xylakant
> 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.

~~~
dho
There is Packagist/Composer: <http://packagist.org/>

------
leftnode
The problem is that PHP is going through growing pains a 15+ year old language
should have fixed years ago, but didn't.

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.

~~~
Klinky
This actually seems to be happening with a lot of the "old workhorse" style
languages. Perl, PHP & Python all seem to be struggling with their
reinventions.

------
bungle
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.

------
deweller
For this item:

"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?

~~~
KrisJordan
Very interesting. How has this not gotten more attention? On first glance this
is pretty much exactly what I was describing would be valuable. Are you the
author?

~~~
romaniv
Well, personally I wouldn't use it, because it doesn't look idiomatic enough.

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.

------
sequoia
"Allow functions to be imported like classes"

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
    

Then `require 'lib/myFunk.php';` I'm sure there are more graceful ways in
other languages but this works. (EDIT: Namespaces notwithstanding ;)

------
BjornW
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.

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.

~~~
KrisJordan
The process of adding channels and installing from them isn't too bad, but
it's still additional friction. You can't do "pear search foo" and hope to
find what you're looking for. Moving system-to-system you have to re-add all
those remote channels you depend on.

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".

------
ericingram
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?

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}!";
        }
    

Which is auto loaded by the framework and usable like this:

(PHP):

    
    
        echo say_hello('World');
    

(Smarty):

    
    
        {say_hello to="World"}

~~~
ericingram
Note: I purposely called it MVc vs. MVC. The controller is minimized in favor
of native REST access to models/resources. If anyone is curious about this,
I'll be writing about the new convention soon.

------
Kudos
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 _some_ level of curation and/or tiering of packages.

~~~
Klinky
Honestly I learned about the PHP mongo extension by going to MongoDB's website
& reading how to get it to work. My first thought was not to do 'pecl install
mongo'. This probably has more to do with 10gen taking the effort to write a
proper extension for PHP rather than letting the community come up with a
module for node.js. Also I don't think node has had time to "settle" since
it's still evolving, so you'll experience package fragmentation like what you
see with mongo.

I do agree that along with package management there should be a strong
community/social component involved that critiques & communicates about
packages available.

------
lux
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
(<http://www.elefantcms.com>), and despite naysaying from the OOPS camp, it
works very well in practice.

~~~
ericingram
I like the approach you took with elefant as an MVC framework. The "handler"
thing is interesting...

~~~
lux
Thanks! Making "handlers" feel like ordinary PHP scripts that execute top-down
seems like the most natural way in PHP, since that's how the language itself
works. It's not much different than inverting the require statement, your
front controller includes your handler after initializing some helpers for you
:)

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.

~~~
ericingram
I agree with you.

My one bit of criticism might be, in a plain php file without any code block
wrapping handler logic, it's harder to understand context. I don't know
exactly where this file is getting executed, and so it's not clear where the
contextual properties are coming from? Perhaps that's the point.

~~~
lux
Hopefully that's where good docs come in ;) But I definitely agree that can
cause confusion if not explained carefully.

~~~
ericingram
Have you thought about releasing the framework separately? I'd be interested
in working with you.

~~~
lux
It's definitely a possibility! That would mostly just be a matter of removing
the default apps and layouts, then cleaning up the configs that pertain to the
CMS. Would make a fun weekend project :)

Releasing the framework separately would take care not to add confusion to the
documentation side of things. Then again, having a separate 'elefant-core'
project that the CMS builds on may even help...

------
PaulHoule
I'd disagree with the exclusive focus on functions. He's right though, about
having better "loader" mechanisms.

You can write simple and concise OO code in PHP without writing Java-inspired
superverbose code.

------
AdrianRossouw
It sounds to me like the author is trying to write php like he would use
javascript.

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?

~~~
KrisJordan
The article's intention was to promote the idea that plain-old functions
should have their place as an equal contemporary to classes. I'm mostly a fan
of PHP's object model, it's more complex than it needs to be in some ways, but
it works. I could write a similar article on JavaScript talking about how it
needs to indoctrinate a class hierarchy paradigm. My understanding is there
are talks of this happening in ECMA.next. But CoffeeScript's model is
currently good enough for me.

