Skip to main content

My new way of using PHP Traits & Interfaces

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 for not forgetting about me!";
     }
}

It's pretty obvious what I'm doing here.  I'm basically writing an interface to add to a class and then creating a trait that fulfils that interface.

This leaves us with "why?"

I think most of the time when someone is going to use your interface, they're going to wish that they didn't have to actually implement the methods it sets out.  Which teaches us a little about how traits came to be: they're purely convenience.
Interfaces are a good idea, no question about it.  It makes code easier to read and follow when you see classes that use them.  Burdening consumers of your library with writing menial code however is not as useful and to a lesser extent so is forcing an implementation with traits.

Using this approach lets someone interested in your library take exactly as much as they need and leave the rest behind.  If all they want is to stay in sync with my library and use the defaults, my trait and implementation will always be in sync, they don't have to worry.  If however for some reason they need to abide by my library's contract but swap out how it's done?  They're fully empowered to do so!

I don't suspect I'm the first person to think of this, however I did come up with it on my own and it seems like a very considerate way to get the best of both worlds.  Enjoy!

Popular posts from this blog

Amazon in Winnipeg?

Late last week, Amazon put word out that they're starting to look for a city to locate a second headquarters.  The fuel this announcement provides has the hype train in Winnipeg going so fast, it's missing stops.

I'm curious though.  As you've been digesting this exciting news, who have you spoken or listened to?
Was it this guy and his party's historic theft of public infrastructure (pdf) and incompetence with digital strategy? Or how about this guy, who maintains that Winnipeg doesn't need a proper rapid transit option?  You know, the kind that might actually catch the eye of handsome Amazon who now has Winnipeg trying to be the belle of the ball.


Runner up articles are Winnipeg's inability to join the 21st centry on active transport and the compounding of the aforementioned digital strategy mistakes.
Stop Listening to These Guys They are not technology experts. At worst, they're unabashed self promoters. At best they're conduits for very bad pol…

Building .NET Core Nuget Packages

My last blog post was on building and publishing npm packages, specifically for typescript projects. In my opinion, packages are an important fundamental unit in software development. They sit at the confluence of technical competence and collaboration, and represent something the software community should be proud of.
Most of the time, you're going to be creating software packages once you're comfortable with some essential pillars: CodingProject structureSoftware architectureBuildingDeliveryCommunityLicensing
After I got my npm package up and running, my next task was to do the same thing with my C# libraries. Similar to protoculture, I have made a library called praxis.  This is done by leveraging the services and tooling known in the .NET ecosystem as nuget.


In this case, praxis abstracts many of the concepts and functionality I require when producing server projects. It builds on top of ASP.NET Core, so in that sense you can almost think of it as a framework-framework. The…

The Cons, Winnipeg's New Splash Pads

I never had the chance to be ungrateful, the new splash pad at Kildare and Wabasha isn't a splash pad at all.  It was taken away from us and replaced with an "aquatic park", a little bit of wordsmithing designed to gloss over the fact that an open piece of our community has been replaced with yet another closed gate.

As I write this post now, I can hear it already: "Taken away, what?! It's a new water park, you're so..."
Sure, some might reach for that tired recrimination, which is why I started this blog post by dismissing such a premise.  To be fair however, I offer the response: Don't spoil this discussion with nonsense.
You see, I was grateful before the renovations happened.  The communal service on offer was adequate and I never complained about it or saw it as flawed.  Don't believe me? Here, this is a cute google-generated animation of my son enjoying the splash pad in 2014.

Today we took the kids to see if we could spend some time at th…