Unconventional

A popular feature in Rails called "mixins" came to PHP a while back under the name "traits".  Traits let library developers give you a lot of functionality with little to no effort by injecting code into your classes that runs as if originally authored in them. Just toss a line of code into the class you want to augment and you're off to the races. The one snag I found when using traits however is that they don't participate in any kind of type system.  If desperate enough, you can use reflection to pull out whether a class has one applied or not, but that's only half the battle and a lot of work each time. This puts me in a slight bind when I'm interacting with classes using a trait I've made as I have no way to type check or hint them in. But then it dawned on me... interface MyInterface { public function thisMethodIsImportant(); } trait MyInterfaceImpl { public function thisMethodIsImportant() { return "Thanks

Are you looking for a way to resolve things like translation, validation and config from the Laravel IoC? Look no further! Make yourself a service provider (whether in a common tools package or in your project) and add the following to it in the register method: $this->app->bind('Symfony\Component\Translation\TranslatorInterface', function ($app) { return $app['translator']; }); $this->app->bind('Illuminate\Config\Repository', function ($app) { return $app['config']; }); What you've done is mapped all the string-registered services to their most abstract but also most specific types.  Config is a good example of where you should be binding the class name and not an interface because the only interfaces it implements are ArrayAccess, and that's obviously wrong! :) Happy constructor-injecting!

At my job, we've been doing a lot of learning and development using Taylor Otwell 's Laravel 4 PHP framework.  As we've become more familiar with it, we've had to come up with better ways to structure our projects outside of what the documentation indicates and the default distribution that is provided. If you've been working with Laravel 4 for any amount of time or come with experience from another framework and are just getting started, you've probably noticed that there are a lot of different ways to cut up your projects. Choice is nice, but sometimes it can be paralysing or misleading. Concrete Advice This post is done in such a way that you can just skim the headings, but if you want a detailed explanation in each section, feel free to read in where necessary. While I can't say the entirety of my advice is in practice throughout the community, I can say that we are starting to use it, and to very good effect at my job.  Especially consider

For anyone configuring their own error handlers in Laravel 4.x, a feature suggestion I made has been implemented to have the handlers placed at the top of the queue rather than bottom. This default behaviour makes more sense given that as you get further into your app, you'll likely be defining handlers less likely to return a response, or more likely to want to pre-empt other error handlers entirely. While that's a safe assumption, there's still the mechanism to add a handler to the bottom of the pile with pushError() if you end up needing it still. Here's a quick reminder of how you can use either of these features: App::error(function (Exception $exception) { /* Your handler here! */ }); App::pushError(function (Exception $exception) { /* Your handler here! */ });