I must not fear.
Fear is the mind-killer.
Fear is the little-death that brings total obliteration.
I will face my fear.
I will permit it to pass over me and through me.
And when it has gone past I will turn the inner eye to see its path.
Where the fear has gone there will be nothing.
Only I will remain.
– Bene Gesserit Litany Against Fear, Dune series of books, written by Frank Herbert
As an Englishman of a certain generation, I was brought up to believe that it was bad to show emotions, that I should keep everything bottled up inside… “stiff upper lip”, “it just isn’t the done thing”, “it’s a sign of weakness”, and all that. If you’re scared, then you should put on a brave face: if things are going badly, then still look cheerful and don’t let anybody know how unhappy you are.
Tonight at midnight (local time) I become a “citizen of nowhere”.
Four or five years ago, the most popular talk that I gave at conferences was entitled “A Functional Guide to Cat Herding with PHP Generators” (the cats proved a very enjoyable talking point at every event where I gave it, because who doesn’t enjoy a technical talk featuring cats); and I even wrote a blog post here about that self-same topic. That presentation described how I was building up enormous volumes of GPX tracking data showing where my cats roamed each day. In order to analyse that data without using equally enormous amounts of memory, I read it directly from the GPX files, using Generators to process each trackpoint one at a time; and and took a map, filter, reduce approach to resolving the questions I wanted to answer about my cats movement habits. Because PHP’s standard array_map(), array_filter() and array_reduce() functions only work with arrays of data, which are expensive in terms of their memory usage, I wrote my own versions of those functions to work with Traversable objects (like Iterators and Generators) as well as with arrays. And the technical body of the talk was how I wrote and used my versions of these functions.
I chose to write the functions myself as a learning exercise, to better understand how they (and Traversables like Generators) worked; but for map and filter, I could just as easily have used the Iterators that already existed in the Standard PHP Library (SPL).
There was a time, back when I was working with PHP 5, when I found the Standard PHP Library (SPL) an extremely powerful and useful toolbox; and I particularly enjoyed working with SPL’s Iterators and Datastructures. Sadly, SPL was always a somewhat forgotten component of PHP, even when it was incorporated into core, probably due to the lack of documentation (although Pete Cowburn and the other PHP documentors did work hard to improve it over the years). With the arrival of PHP 7, SPL seems to have dropped even further into a backwater: generally we create our own exception classes, though we may sometimes use those in the SPL; we rely on Composer to handle autoloading, rather than using SPL directly to set up our autoloading manually; and Datastructures (one of my favourite SPL components) are better implemented in Rudi Theunissen’s ext-ds library.
But although much of the SPL is now outdated, or has been superseded by better language elements; some components are still useful. SPL’s Iterators are confusingly named, and there’s little in the documentation that explains when and how they can/should be used, but if you can learn to understand them, they are still powerful tools even with PHP 7; especially as they work with any Traversable (like Iterators and Generators, or the Collection objects provided by many frameworks), not simply with arrays.
I’m always nervous when I speak at a conference or in front of a user group; but I also enjoy sharing my passion and excitement for things that I’ve learned, or new tools that I’ve discovered. That makes it particularly difficult for me to withdraw from a conference where I’ve already committed to speak, not giving just one talk, but two. But sometimes it is necessary to stand by my beliefs, despite the fact that it causes disruption to the conference organisers when they’ve already announced the schedule, and means that I can’t share my passion for coding with the attendees at that conference.
That’s the position that I found myself in barely a week ago.
At New Year, many people write a retrospective of the old year, and about their hopes and dreams for the new.
The roots for my own changes over the last year really lie earlier: 2017 was the year when a health scare saw me rattling around the PHPNW Conference spaced out on a cocktail of drugs as the doctors tried to figure out what was wrong with me. My memories of the Conference are very fragmented, and the medics never did figure out the problem: fortunately my body resolved the situation (whether assisted by the drugs or not); although I spent much of that last Christmas/New Year period in agony from the side effects of some of the medications that I’d been prescribed.
But mentally at the beginning of 2018 I was also in a really bad state.
I’ve written before about the benefits of using PHP’s Anonymous Classes for test doubles; but Anonymous Classes also have potential usecases within production code as well. In this article I’m going to describe one such usecase that can be particularly useful within libraries, and that is replicating the access of Package Private (in Java), or Protected Internal Classes (as per C#).
In Java, a Package Private class will be accessible to other classes in the same package but will be inaccessible to classes outside the package, meaning that it isn’t possible to create an object of that class or to declare a variable of that class type. In C#, Internal or Protected Internal Classes enable a group of components to cooperate in a private manner without being exposed to the rest of the application code. Access to Internal Classes is limited to the assembly in which they exist, or can be granted to specific “friend” assemblies.
This class visibility simply in’t available in PHP, but it could be useful for library writers to have that control over visibility of the classes inside their packages that are only intended for internal use.
In the first article in this series, I wrote about the problems with testing static methods in classes, and showed a few approaches that allow us to write mocks for statics. Testing classes where we have static properties is a lot harder to manage, because any changes made in any test to those properties are global, across the entire test suite, not simply the test that we are running. Static properties are part of the global state, and we can’t simply
tearDown() those changes in the way that we do with instances — at least we cannot easily do so if the property has a visibility of private or protected.
Posted in PHP
Tagged PHP, Static, Testing
If you’ve read my previous post (Discharging Static #1), then you’ll know that recently I’ve been exploring different approaches to creating test doubles for statically called methods, and other testing problems, and had begun to look at Michael Bodnarchuk’s AspectMock library as an alternative to Mockery. Much as I like Mockery, and have no issues with it when tests are run standalone, it can be problematic when running the whole test suite; whether upstream tests have already autoloaded the classes that you need to mock, or breaking downstream tests, even when calling
Mockery::close() as part of the PHPUnit
AspectMock is a stubbing/mocking library written as part of the Codeception test framework, but which will also work with PHPUnit; and which provides functionality that not only allows mocking of both static and instance methods, but can also mock functions (including PHP’s built-in functions, as well as userland functions). It can achieve all this because it is built on the The Go! AOP framework for PHP. Exploring how this worked introduced me to the AOP (Aspect Oriented Programming) paradigm; and I feel like I’ve taken the red pill, followed the white rabbit down the hole, and entered the surreality of Wonderland.
Posted in PHP
Tagged AOP, Aspect, Go!, PHP
It’s been seven years since Kore Nordmann first published “static considered harmful” on his blog, explaining the problems with using static method calls in classes, and the difficulties that they cause when trying to test that class. Seven years on, and those difficulties are still the same, and there is still new code being written using static calls despite that knowledge; but it’s often a more severe problem in legacy code with little or no unit tests.
So why exactly are static calls so bad? If you’ve read Kore’s article, then you probably have a good idea already; but what that article doesn’t cover is approaches that we can use to make the code testable.
Posted in PHP
Tagged PHP, Static, Testing