PHP is in a metamorphosis.
A quickening.
This is not the result of one thing, but the sum of many smaller things coming together, seemingly, at the same time.
| SUM OF THREE THINGS |
|---|
| PHP Language Improvements (5.3/5.4) |
| PHP Framework Interop Group |
| Composer Dependency Management |
This digest aims to identify key php trends, so that we can determine if we need to correct our course to stay competitive and relevant in our future coding efforts.
PHP Language Improvements
Abit slow, php is evolving and the most relevant of these changes can be seen in later versions of the php 5.x releases where the focus moved from stability, speed and functionality improvements to languages improvements, specifically designed for framework development – these changes can drastically redefine how we architect our applications.
A couple of the biggest game changers, are Namespaces and Closures.
Namespaces
PHP Namespaces remove the need for long, PEAR-style class names (e.g. Slim_Middleware_Content_Types) while still avoiding class name collisions with other libraries.
namespace ARX\Logging;
Namespaces are a way of encapsulating items to prevent collisions between code you create, and internal PHP classes, functions and constants or the same found in a third-party library.
It also provides the ability to alias (or shorten) Extra_Long_Names improving code readability.
use ARX\Logging as log;
$log->error('This is so wrong, its right', 200);
Closures/Anonymous Functions
Anonymous functions allow the creation of nameless functions which lend themselves great as callback parameters.
Borrowed from the Functional Programming world, PHP now supports first-class functions, meaning that a function can be assigned to a variable. Both user defined functions and built-in functions can be referenced by a variable and invoked dynamically.
Functions can be used as arguments to other functions and a function can return other functions as a response.
//assigned to a variable
$me = function() {
return 'My Name is Fred';
}
// as a callback
$app->get('/', function () {
echo "Hello World!";
});
Newer PHP frameworks take advantage of Anonymous Functions/Closures for some architecture decisions. While I find use cases limited to callbacks and framework router workflows, this is a powerful construct - especially independent data scope mentioned at the bottom of this article.
PHP Framework Interop Group
The PHP community is large and diverse, composed of innumerable libraries, frameworks, and components. It is common for PHP developers to choose several of these and combine them into a single project. It is important that PHP code adhere (as close as possible) to a common code style to make it easy for developers to mix and match various libraries for their projects.
The Framework Interop Group (formerly known as the ‘PHP Standards Group’) has proposed and approved a series of style recommendations, known as PSR-0, PSR-1 and PSR-2. You can read more about these standards here:
- PSR-0 relates to Autoloader Interoperability
- PSR-1 relates to Basic Coding Style
- PSR-2 expands on the Coding Style
These recommendations expand on the previous recommendation.
These recommendations provide a set of rules that a large majority of php projects/frameworks are adopting at different levels, such as:
- Laravel 4 will support PSR-0, PSR-1
- Slim 2 supports PSR-0,PSR-1, PSR-2
- FuelPHP 2 will support PSR-0, PSR-1
- CodeIgniter 3 will support PSR-0
- Symfony 2 supports PSR-0, PSR-1, and PSR-2
- Zend 2 supports PSR-0
Ideally you should write PHP code that adheres to one or more of these standards so that other developers can easily read and work with your code, and applications can consistently extend and interoperate with third-party code.
PSR-0 Autoloading Interoperability
Autoloading in PHP has been a bit of a mess for some time, as every developer has his or her own ways of handling things. Some packages, like Smarty, use their own autoloading, some developers place multiple classes into one file or have lower-case file names – it’s all very random.
PSR-0 is a standard, created by the PHP Standards Group, to calm this mess down; As you will see later, Composer will work with it by default. Composer bundles with a PSR-0 autoloader, which you can include in your project with only a single line:
include_once './vendor/autoload.php';
PSR-1 Basic Code Style
There’s nothing worse than inheriting an application or needing to make changes to code that requires a lot of energy to decipher… you end up trawling through lines and lines of code that doesn’t make its purpose or intentions clear.
Whats worse is your source control screams at different character encodings, your editor jumbles code because indentation inconsistently and when you just want to instantiate that new object like everywhere else in your code you cannot because a third-party library defined the class name as myObject rather than MY_Object.
Having a defined coding style guide, helps insure a project doesn’t die from a thousand little cuts.
PSR-1 is THAT very basic style guide, and expands on PSR-0 adding basic code and file formatting rules such as:
- PHP tags
- Character Encoding
- Namespacing Usage
- Class/Method/Constant Naming
PSR-2 Expanded Coding Style
PSR-2 expands on PSR-1.
The intent of this PSR-2 is to reduce cognitive friction when scanning code from different authors. It does so by enumerating a shared set of rules and expectations about how to format PHP code.
The style rules herein are derived from commonalities among the various member projects. When various authors collaborate across multiple projects, it helps to have one set of guidelines to be used among all those projects. Thus, the benefit of this guide is not in the rules themselves, but in the sharing of those rules.
Composer Dependency Management
It is pretty rare to find a developer who actively uses systems like PEAR. Instead, most developers have chosen their favorite framework, which has code specifically written for it to handle various things, like DB interaction, ORM’s, OAuth, Amazon S3 integration, etc.
The downside here, though, is that switching frameworks (or returning to not using a framework at all) can be a nightmare, as it involves relearning everything to use brand new tools – and that is no easy task.
Composer sets out to solve this situation by positioning itself as “the glue between all projects” – meaning that packages can be written, developed and shared in a format that other developers can plug into other applications with ease.
Composer makes it super easy to declare and autoload your project’s dependencies without worrying about writing or registering your own autoloaders.
And setting up Composer is fairly painless:
curl -s http://getcomposer.org/installer | php
With Composer installed we would create a composer.json file in the web root that indicates the dependencies you want to install, as an example showing Slim PHP:
{
"require": {"slim/slim": "2.*"}
}
This says install the latest 2.x branch of Slim. Then we install our dependencies via composer like this:
php composer.phar install
Composer organizes libraries in a vendor/ folder with subfolders identified in your composer.json file.
For example:
vendor/
arx/
composer/
slim/
autoload.php
All libraries installed this way are available via one include:
require 'vendor/autoload.php';
Composer has a side kick too! Check out The Packagist to see all of the libraries and frameworks that support Composer - way more than PEAR!!
Where Do We Go From Here?
Lets start an open discussion on how to get our code working for us, rather than against us.
Back-End Ideas:
- Migrations (Time Based)
- Custom Code Generators / CLI Tool
- Unit Tests
- Build Component-Based Libraries (as Separate Projects)
- Migrate to a Composer-based framework (Laravel 4?)
Front-End Ideas:
Notes
- Most of this document is a direct plagiarizing of internet news sources, personal blogs, and books. Think of this as a digest of trends facing the future of PHP.
To give credit where credit is due, here are a few sources that inspired this digest.