Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

Freek Van der Herten:
Method overloading is possible in PHP (sort of)
Oct 21, 2016 @ 09:33:41

Freek Van der Herten has a post to his site showing how PHP functions can (sort of) be overloaded with the help of a trait from Adam Wathan.

PHP does not support method overloading. In case you’ve never heard of method overloading, it means that the language can pick a method based on which parameters you’re using to call it. This is possible in many other programming languages like Java, C++.

However, with some clever coding, Adam Wathan made a trait, aptly called Overloadable, that makes method overloading possible. It works by just accepting any parameters using the splat operator and then determining which of the given functions must be called according to the given parameters.

He shows how to use the trait in a simple example, defining a single "bar" function and using the "Overloadable" trait to handle the switching between the methods based on the input variables. You can find more information about the trait and the source for it in this gist over on GitHub.

tagged: method overload trait custom splat operator variable

Link: https://murze.be/2016/10/method-overloading-possible-php-sort/

SitePoint PHP Blog:
Control User Access to Classes and Methods with Rauth
Mar 17, 2016 @ 13:55:22

The SitePoint PHP blog has posted a tutorial from Bruno Skvorc showing you how to use Rauth, a tool that's designed to control access to parts of your application as set by annotations in the code.

Rauth is SitePoint’s access control package for either granting or restricting access to certain classes or methods, mainly by means of annotations.

[...] Traditional access control layers (ACLs) only control routes – you set anything starting with /admin to be only accessible by admins, and so on. This is fine for most cases, but not when: you want to control access on the command line (no routes there) or you want your access layer unchanged even if you change the routes Rauth was developed to address this need. Naturally, it’ll also work really well alongside any other kind of ACL if its features are insufficient.

He starts by dispelling the common thought (at least in most of the PHP community) that annotations are a bad thing and relying on them for functionality isn't a good practice to follow. With that out of the way, he shows a simple example: a set of users and fake routes that are evaluated by Rauth based on the annotations in a One controller-ish class. He describes what the evaluation is doing and how changing the annotations would make a difference in the results. He also includes a dependency injection example with PHP-DI and the Fast-Route package and a more "real world". He ends the post with a look at another handy feature of the library: bans (blocking based on other types of annotations, @auth-ban).

tagged: rauth access control class method annotation tutorial

Link: http://www.sitepoint.com/control-user-access-to-classes-and-methods-with-rauth/

Intracto Blog:
Paying Technical Debt - How To Rescue Legacy Code through Refactoring
Mar 17, 2016 @ 09:36:16

On the Intracto blog there's a new article posted from Jeroen Moons with some suggestions you can use to pay down technical debt in your legacy code through a bit of effective refactoring.

I have good news for you! Squirrels plant thousands of new trees every year by simply forgetting where they leave their acorns. Also: your project can be saved.

No matter how awful a muddy legacy code mess your boss has bravely volunteered for you to deal with, there is a way out of the mire. There will be twists and turns along the way, and a monster behind every other tree. But, one step at a time, you will get there.

He gives lost of different suggestions for things that can be done to "save your code" and make it not only easier to maintain but more flexible:

  • Persuading the customer
  • Don't replace [a huge mess] with a new one
  • Make problems visible
  • Fight what hurts most
  • Build a library

There's plenty more great suggestions here too with some thoughts and methods to back them up and help you accomplish them in your own code. If you're suffering through a large legacy codebase from day to day, I highly recommend reading through this article.

tagged: technicaldebt legacy legacycode rescue opinion method refactor

Link: http://marketing.intracto.com/paying-technical-debt-how-to-rescue-legacy-code-through-refactoring

Robert Basic:
Tags for PHP in Vim
Mar 10, 2016 @ 11:32:34

In a post to his site Robert Basic has shared some helpful plugins for PHP developers using Vim as their primary editor. These plugins not only help you jump around in your code but get more context on where you're at.

One thing I was missing for a long time in Vim is to be able to "jump to definition" in an easy and painless way. The other thing I wanted to improve is to be able to tell easily where am I actually in the code base; to see the current class and method name of wherever the cursor was.

With a bit of googling and poking around, I finally came up with a perfect combo of 5 plugins (yep, five!) that enables me to do both, and a little bit of extra.

He shows examples of using three different things he wanted to be able to do when working in his code and the plugins that satisfy each:

One line examples are included showing how to configure them with your current Vim use.

tagged: tags vim plugin jump definition context class method

Link: http://robertbasic.com/blog/tags-for-php-in-vim

Questioning PHPUnit Best Practices
Feb 05, 2016 @ 12:13:04

In this new post to thePHP.cc blog Sebastian Bergmann (creator of the PHPUnit unit testing tool) questions of some the current "best practices" involved in using the tool. More specifically he looks at the handling for expected exceptions and proposes a new practice to use going forward.

It is important to keep in mind that best practices for a tool such as PHPUnit are not set in stone. They rather evolve over time and have to be adapted to changes in PHP, for instance. Recently I was involved in a discussion that questioned the current best practice for testing exceptions. That discussion resulted in changes in PHPUnit 5.2 that I would like to explain in this article.

He talks about the currently widely used practice of the @expectedException annotation to define when an exception should be thrown from the code inside the unit test. Sebastian talks about the evolution of this into other annotations around the code and message returned from the exception too. He then proposes the new best practice as a result of some discussion around the annotation method: returning to the use of the setExpectedException method. He provides some reasoning behind the switch including the timing of the exception being thrown (not just "any time" but a more specific time).

tagged: phpunit bestpractice expected exception annotation method expectedexception

Link: https://thephp.cc/news/2016/02/questioning-phpunit-best-practices

Anna Filina:
Testing Methods That Make Static Calls
Jan 13, 2016 @ 09:03:40

Anna Filina has posted a quick hint around testing methods that make static methods calls to other parts of your application. Static method calls are notoriously difficult to test, especially with PHPUnit.

I had trouble testing a particularly painful codebase. It had static calls and implicit dependencies all over the place, to name just a few problems.

One of the things that it often did was to call static methods that would increment counters in the database and cache stuff. Example: Record::incrementViews() It was making things difficult. To avoid messing with the original codebase too much, I came up with this quick and dirty way to ignore those dependencies.

Her solution makes use of a mockStaticDependency method that then turns around and redefines the class in question (like her "Record" above) with a __callStatic through an eval. She points out that usually using eval is "evil" but in this case it made testing the functionality much simpler when no feedback was needed from the static method. In the comments on the post, someone also makes a recommendation of the Patchwork library for PHP that allows for "monkey patching" and modifying classes/functionality to redefine functions and methods in a similar way.

tagged: unittest method static call monkeypatch eval callstatic example

Link: http://afilina.com/testing-methods-that-make-static-calls/

Ross Tuck:
Formatting Exception Messages
Oct 27, 2015 @ 12:09:39

In a post to his site Ross Tuck shares some of his experience and some helpful hints around formatting exception messages and how doing so effectively can make life for fellow developers much easier.

Over the last couple years, I’ve started putting my Exception messages inside static methods on custom exception classes. This is hardly a new trick, Doctrine’s been doing it for the better part of a decade. Still, many folks are surprised by it, so this article explains the how and why.

He shares his tips as a part of a "refactoring" in a simple example, a CSV import where there are failures during the import process on certain lines. He starts with the basic Exception and works through the logic to customize it and make it more useful. He shows the inclusion of additional details in the message, abstracting out the formatting to custom methods based on the error type and using static methods for the more complex message formatting. He also suggests the creation of methods to handle specific error cases with more details than a simple single-line error in a normal exception being thrown.

When you co-locate the messages inside the exception, however, you gain an overview of the error cases. If these cases multiply too fast or diverge significantly, it’s a strong smell to split the exception class and create a better API. [...] Sometimes we underestimate the little things that shape our code. [...] Creating good environments at a high level starts with encouraging them at the lowest levels. Pay attention to what your habits encourage you to do.
tagged: format exception message custom method details static

Link: http://rosstuck.com/formatting-exception-messages/

Symfony Blog:
Paving the way for Symfony 3 with the "Deprecation Detector" tool
Oct 22, 2015 @ 10:48:31

On the Symfony blog there's a post talking about a tool they've introduced that is helping to "pave the way" for the upcoming version 3 release of the Symfony framework - the Deprecation Detector tool.

Symfony 3 will be released at the end of November 2015. Learning from our own history, the transition from Symfony 2 to 3 will be much more pleasant than the transition from symfony 1 to 2 that happened in July 2011.

Technically speaking, Symfony 3 includes no new features comparing it with Symfony 2.8, which will be released at the same time. [...] This means that your Symfony applications won't work on Symfony 3 unless you remove all their deprecations. In order to simplify the task of finding which deprecations affect your applications, a new tool called Deprecation Detector has just been released.

The tool runs static analysis against your codebase and finds locations where you're using deprecated methods/classes/interfaces/etc and reports them back for fixing. The post includes the commands you'll need to get the tool installed and how to run it against your code. You can find out more about the project and get details on command line options on its GitHub repository.

tagged: deprecation detector symfony2 symfony3 method interface class service tool tutorial

Link: http://symfony.com/blog/paving-the-way-for-symfony-3-with-the-deprecation-detector-tool

Gonzalo Ayuso:
Alternative way to inject providers in a Silex application
Oct 19, 2015 @ 11:18:10

Gonazalo Ayuso has shared a method he's found for injecting providers into Silex that replaces accessing the dependency injection container as an array. It instead replaces it and allows defining function parameters instead.

I normally use Silex when I need to build one Backend. It’s simple and straightforward to build one API endpoint using this micro framework. But there’s something that I don’t like it: The “array access” way to access to the dependency injection container. I need to remember what kind of object provides my service provider and also my IDE doesn’t help me with autocompletion. OK I can use PHPDoc comments or even create one class that inherits from SilexApplication and use Traits. Normally I’m lazy to do it. Because of that I’ve create this simple service provider to help me to do what I’m looking for. Let me explain it a little bit.

He includes examples of both the normal way you can access Silex's injection containers (the "array access" method) and contrasts this with his updated method, via a method parameter on the route closure. His service provider (complete code in the post and on github), when registered, looks for controller events and performs reflection on the closure to detect which objects need to be injected. The method is then called normally but with the extra attributes set, populating the parameters.

tagged: slex service provider alternative array access parameter method dependency injection

Link: http://gonzalo123.com/2015/10/19/alternative-way-to-inject-providers-in-a-silex-application/

Paul Jones:
A Factory Should Create, Not Retain
Jul 08, 2015 @ 08:45:31

Paul Jones has posted his thoughts about factory behavior in PHP applications (well, really any kind of application as it's a pan-language concept). He suggests that factories should only create the objects requested and not persist them.

In a recent Reddit conversation, some of us went off on a tangent about factories. I maintained then, and do now, that a “factory” always-and-only returns a new instance. If you have a “factory” that returns anything other than a new instance, it’s not a factory alone. In the case of factory methods, it is a factory + accessor; in the case of factory objects, it is a factory + registry. A “factory” (whether a factory method or factory object) is one way to separate object creation from object use.

He gives an example of a case where an object needs to be created for a "doSomething" method. His first example shows the creation of the "Item" inline, mixing the creation and use of the object into the same place. He replaces this with a "factory" class/method that only returns the new "Item" requested. He points out that a factory method that retains the object (like as a class property) has the same problem as the first example - retention. Instead he suggests an intermediate "collaborator" that splits out the creation and retention once again.

tagged: factory retain create object method collaborator example

Link: http://paul-m-jones.com/archives/6161