Interop & Common Names


I’ve noticed a trend in various interop projects. Often, the proponents of the proposal will “poll” or observe various frameworks and try to pick the most common name in existence for the various interface methods. For example, in a Container interop proposal, the “get” method name might be chosen to retrieve a service from the container.

However, within the context of PHP, this approach couldn’t be more flawed. In my opinion, it’s the exact opposite of what they should be doing. A more verbose, less common name should be chosen. Here’s why.

In languages like C# which support method overloading, the same function may be defined multiple times with a different signature. For example:

public function get(String service);
public function get(String service, Boolean fresh);

So, in a language with overloading, it doesn’t matter as much what method names an interop interface chooses. If I already have that method with a different signature, it doesn’t matter. The same method can be defined multiple times as long as they have different signatures.

This is not possible in PHP. I can only define the method once with a single signature. Since most containers use a “get” method, using that name in an interop interface greatly limits the actual implementation that can ever be achieved by that container without choosing another method name (which might break backwards compatibility). Even if the two signatures do not conflit now, what if they do later? It is better if the interop interface selects a more verbose, less common name like “resolveService”, while the implementations use the more common “get” method to provide their own unique signatures and implementations. Most likely, the “resolveService” method would simply call “get” with a standard set of parameters.


Full IoC & Unit Testing With Laravel


Over the past few weeks, there has been some discussion about dependency injection, service location, and Laravel facades. So, I thought I would put together a quick video to demonstrate how Laravel supports both service locating facades and full-on, thorough dependency injection. In fact, not only does it support it, Laravel is one of the only full-stack frameworks that offers thorough IoC (even for controllers) out of the box. I also included basic unit tests. No facade calls in the entire application.

Enjoy and be sure to watch in 1080p HD!


Response: Don’t Use Facades


This afternoon an article was posted to Reddit that cautioned users of Laravel to stop using “Facades”.

In the context of Laravel, Facades are what you are using when you make what appears to be a static call to a class. For example:

Route::get('/', 'HomeController@showWelcome');

However, as many of you are already aware, this call may be rewritten like so:

$app['router']->get('/', 'HomeController@showWelcome');

The code may be written easier way because, at their core, facades are syntactic sugar for service location. When you make a call to a Facade, the Facade resolves the underlying class out of the Laravel IoC container and calls the intended method on the instance. They provide a very terse, expressive syntax, while still maintaining the ability to test your code.

However, service location can lead developers into some bad architectural habits. For instance, since service location is very “easy”, it can lead to responsibility bloat in your classes. Generally, classes with small, focused responsibilities are to be desired since they are easier to understand, test, debug, etc. However, if you are using Facades to push to the queue, send an e-mail, and validate some data all within a single class, that class’ core responsibilities are obscured. It is concerned about way too many things.

It is possible to use Facades responsibly and keep your class responsibilities narrowly focused. However, some prefer the discipline that constructor injection provides. Constructor injection means that a class’ dependencies are injected via the constructor when that class is created. It is an explicit declaration of what that class needs, and therefore gives an idea as to what that class does.

Before today, injecting the underlying class behind a facade required some explicit bindings to be registered in the IoC container; however, starting today, it is now just as easy to inject your dependencies as it is to use a Facade. By simply type-hinting the class underlying the Facade, it will automatically be injected by the container when it is needed as a dependency.

For example, need an instance of the Session injected into a controller? Just do this:


class HomeController extends BaseController {

	public function __construct(Illuminate\Session\Store $session)
		$this->session = $session;


There is no longer any need to do any extra configuration. Since all controllers are automatically resolved by the Laravel IoC container, the session instance will automatically be injected. Injecting the class underlying the Facade is just as easy as using the Facade itself! If you love using Facades, keep on using them, just keep an eye on those class responsibilities! If you prefer constructor injection, it just got a heck of a lot easier!

If you’re not sure what class to type-hint, check out the Facade To Class Reference from the Laravel documentation.


Unifying PHP


Over the last few weeks, there has been lots of talk about PHP community, packages, and tribalism. So, I thought I would offer a few thoughts on the topic. Currently, Laravel is the most eclectic full-stack PHP framework in existence. In other words, Laravel is the only full-stack PHP framework that actively eschews tribalism.

Laravel, in additions to using its own custom packages like Eloquent and Blade, utilizes a whopping 23 packages from the wider PHP community. Using the “best of the best” PHP packages allows for greater interaction between Laravel and the wider PHP community. But, perhaps more importantly to you, it helps you write amazing applications at breakneck speed.

We don’t want to just speak about community, we want to participate! It’s been a blast to coordinate and talk with developers of so many awesome packages, and I’m very thankful that Laravel has been made better by their efforts.

So, in this post, I want to highlight just a few of the wonderful packages that make Laravel awesome.

A few highlights:

Carbon: An expressive date library by Brian Nesbitt. This library is used to power Eloquent’s date mutators. It makes working with dates in PHP easy and enjoyable.

Predis: A robust Redis client authored by Daniele Alessandri. Predis powers all of the Redis interaction Laravel offers, including the Redis cache, session, and queue drivers.

Phenstalk: Full-featured PHP client for the Beanstalkd queue. Powers the Laravel Beanstalkd queue driver.

SuperClosure: Written by Jeremy Lindblom, this powerful library allows you to serialize and unserialize PHP Closures. It is used each time you push an anonymous function onto a queue.

Whoops: Displays the pretty error pages and stack traces while Laravel is in development mode.

Monolog: The de-facto standard of PHP logging libraries. Used for all logging. Primarily written by Jordi Boggiano.

Boris: Really slick PHP REPL which powers the amazing “tinker” console command.

PasswordCompat: Powers the secure Bcrypt hashing that is used by default by Laravel. Forward compatible with PHP 5.5. Written by Anthony Ferrara.

Symfony HttpFoundation: Extremely robust HTTP abstraction. Well tested and proven in many large, real-world applications. One of the most important community packages we use.

Symfony Routing: This package powers the compilation of Laravel routes to regular expressions, a trickier task than you might think! This library handles a lot of edge cases very well!

Symfony HttpKernel: The HttpKernel provides HTTP exceptions, which are used to indicate 404 responses in Laravel. Also, and perhaps more importantly, this package contains the HttpKernelInterface which is used as the bottom-level abstraction for a Laravel application.

Symfony BrowserKit: All that slick functional testing that Laravel offers? Powered by Symfony BrowserKit!

StackPHP: This project outlines a structure for building reusable, framework agnostic middlewares at the HTTP layer. Utilized in Laravel 4.1+ for all cookie encryption, sessions, and more. Developed by two of my favorite and most respected PHP developers: Igor Wiedler and Beau Simensen.

On Community


This week, Laravel became the most popular PHP project on Github.

I released Laravel two and a half years ago, while living in a small apartment with my wife and newborn son. I built the initial version of the framework on a plastic, $300 laptop from Best Buy with a dim screen and horrible keyboard. I doubted anyone would use it, and it received a mixed reception on Reddit. I bragged to my wife that it received 100 downloads in the first 24 hours of its release.

On the first version of the Laravel website, there were four questions to help you determine if the Laravel framework was “right for you”. One of them, and the most important of the lot, was: “you love friendly, vibrant communities of people committed to helping one another.” Maybe it was the most important because it’s what I wanted the most for myself? Maybe I didn’t write Laravel for technical reasons, but for personal reasons? Maybe I wrote it in hopes of just being a part of something bigger than Arkansas could offer?

Regardless, the Laravel forum soon had a dozen regular members. People who were excited and passionate about building great applications. People who wanted to be web “artisans”. We weren’t there, but we wanted to be. It was a blast, and we were all part of something new and exciting. I bragged to my wife when Laravel got a re-tweet from someone with 500 followers.

The type of community Laravel has is something to be guarded. When you join this community, you join in the responsibility to preserve it. Everyone is at a different point in their journey as a programmer. Some are just beginning, while others have adventured for years. But, everyone belongs. Help them where they are.

When Laravel took the top spot on Github this week, I bragged to my wife. She smiled and gave me a high five. In that moment, I didn’t think about all the cool Eloquent features. I didn’t think about when I first wrote Blade. I didn’t think about any Composer packages. I just thought about the community that made this journey with me.

Someday Laravel will be over and we’ll all be doing bigger and better things. When that day comes, I’ll never reminiscence about the patterns. I’ll only remember the people.

A lot of fresh, aspiring Artisans will join us this year. Let’s help them on their journey.