On the Exakat blog there's a new post sharing five uses of the "static" keyword in PHP applications. This includes the less common static closures and static class names.

Static is a PHP keyword with many usages. It is almost universally used, though there are many variations of it. Let’s review all the five of them :

• static method
• static property
• static closure
• static variable
• static as a classname

The post goes through each of the items in the list giving a brief explanation of how it's used and a code example showing it in action. The post finishes with some tips on evaluating your own code for the use of "static" and tips for each to make your code easier to wrangle and maintain in the future.

On the Laravel News site, there's an article posted covering the use of factory callbacks and closures in guards in Laravel. This feature was snuck into a recent release and allows you to provide a bit more dynamic functionality to your models and guards.

Two undocumented (before today anyhow) features were recently added to the Laravel 5.6 documentation, and they are both fantastic!

The post details each of the two new additions starting with the factory callbacks allowing you to perform additional tasks when a model is made or created (code examples included). The guard changes allowing closures and the Auth::viaRequest method to define new guard drivers.

On the Laravel News site there's a new tutorial posted showing you how to use the "optional" helper and closure to help control issues where a property or method doesn't exist (or can't be accessed).

The Laravel Optional class and accompanying optional helper were introduced in Laravel 5.5. This class is useful to avoid those pesky Trying to get property of non-object errors in your code.

Joseph Sibler submitted an improvement to the Laravel optional helper that we covered in Laravel 5.6.13 which now allows a closure that is only called when the object is not null

They compare the "optional" functionality to the null coalesce operator and the cases when the former should be used over the latter. A few code snippets also help to illustrate the difference. For more information about this helper and other handy features, check out their other article with a "top 5" list of their favorite helpers.

Mark Baker has returned with a new part of his series looking at the use of anonymous classes and closures as an alternative to the typical test mocking functionality. In this latest part (part four) he talks more about the "SpyMaster" class created in the previous article and how it can be refactored to provide the spies with a "mission".

In a prior article in this series, I described the use of a SpyMaster Class to create proxy spies as anonymous classes, that allow external visibility (and potentially update) of protected and private properties within an object. The same basic principle of a spy can also be used to create a proxy that gives us access to execute the private and protected methods of an object.

[...] Unlike the original SpyMaster that I wrote about last July, we’re going to take a slightly different approach here, providing our spies with a “mission”.

He first shares the code for the old class and covers why it was useful. He then moves on to the refactor, showing how it defines the "mission" (what to mock) and an "invoker" that helps with the actual execution. He gives an example of this new class in use, performing an "infiltration" on a sample object and calling previously protected methods directly.

On the TutsPlus.com site there's a new tutorial posted introducing you to task scheduling in Laravel, a feature that allows you to run code in the application periodically similar to a cron job.

In this article, we’ll go through one of the exciting features of the Laravel web framework—task scheduling. Throughout the course of this article, we’ll look at how Laravel allows you to manage scheduled tasks in your application. Moreover, we’ll also end up creating our own custom scheduled tasks for demonstration purposes.

The Laravel framework allows you to set up scheduled tasks so that you don't have to worry about setting them up at the system level. You can get rid of that complex cron syntax while setting up scheduled tasks since Laravel allows you to define them in a user-friendly way.

The article starts with a brief introduction to cron jobs, how they're set up and some issues that come along with them. Next the article describes the "Laravel Way" of handling task scheduling, showing how to use Laravel's artisan command to run the scheduler. With the basics laid out, the author then walks through how to create a custom task either using a closure/callable, making an artisan command or using the exec command. Code examples are included for each and more information about scheduling options and functionality can be found in the Laravel manual.

Mark Baker has posted the third part of his series looking at an alternative way to handle mocking in the tests for your PHP application. In this latest part of the series he shows how to modify one of PHPUnit's own mocking examples to use an anonymous class.

I have heard people say that you shouldn’t test abstract classes or traits, only the concrete classes that implement or use them. I don’t follow that approach: unit testing is all about testing in isolation from anything that might affect those tests. Testing a concrete class that implements an abstract one, or uses a trait, means that the abstract class or trait is no longer fully isolated, but is being tested within the scope of the whole of that concrete class. We should still always test concrete classes as well; but we should also test the abstract classes and traits as individual units.

So just how do we test something that cannot be instantiated on its own?

He shares one tactic that some developers use - a class designed only for testing - but suggests that this "pollutes" the codebase. Instead he shows how to replace mocking for traits and abstract classes with an anonymous class that's more "disposable". He also shows how to modify this approach to handle calling protected methods in the class the anonymous class extends.

Mark Baker has posted the second part of his series covering the use of closures and anonymous classes as an alternative approach to mocking in your unit tests. In part one he introduced some of the basic concepts behind their use and in this latest post he focuses on "different approach to using an Anonymous Class to verify the values of object properties".

The last time I posted here, I was writing about Anonymous Functions and how they can be bound to any object (or class) to execute as though they are a method within the scope of that class (Closure Binding as an alternative to “use” variables); and in the first article in this series, I looked at using a Closure to access private and protected properties of an object.

I was going to write this particular article about using simple Anonymous Classes to create test doubles for Unit Testing – and may well return to that topic in a future article in the series – but Matt Brunt has written a good post on that topic already, so instead I’m going to focus on a different approach to using an Anonymous Class to verify the values of object properties that we otherwise couldn’t see directly when testing a class.

He goes on to talk about some ideas from the Java ecosystem around nested classes and scoping. He then shows how, with closure binding, the same kind of effect can be created in PHP testing. He includes the code for an example of a class that coverts distance measurements. He then introduces his "SpyMaster" utility class that "infiltrates" the class under test and attaches the closure providing the needed point for testing. He finishes up the post talking about this functionality and how the technique can be used in many places, not just testing class constructors.

On the Laravel News site there's an article covering custom validation objects and using them in a Laravel-based application. This validation handling is added in Laravel v5.5 (upcoming as of the time of this post) to allow for easy extension of current validation rules.

Laravel 5.5 will introduce support for custom validation rule objects as an alternative to using Validator::extend for custom validation rules.

To define a custom validation rule, implement the IlluminateContractsValidationRule interface or use a Closure. The custom rule is then used directly in a validator.

They provide a few examples of defining these objects, using the "passes" and "message" methods defined in the interface. It also shows how to put them to use in a "validate" call on a request using both the object and closure versions. This new custom validation handling helps to replace some of the difficulty with the previous extension methods and makes it more flexible by allowing closures.

Robert Basic has written up a new tutorial for the unit testers out there showing how to do some complex argument matching in Mockery, a popular testing tool that offers an alternative to PHPUnit's own mocking functionality.

This past weekend I did some issue maintenance and bug triage on Mockery. One thing I noticed going through all these issues, is that people were surprised when learning about the Mockery::on() argument matcher. I know Mockery’s documentation isn’t the best documentation out there, but this still is a documented feature.

He starts with a simple mock example, mocking out AClass and defining two method criteria (one with a once and another with a never). He points out that things are not always that simple and sometime more complex argument matching is required. The Mockery:on handler allows you to pass in a closure and do more complex evaluation of the values passed in. He includes an example of this, evaluating the result of a set of arguments passed in and ensuring they're all set.

Matthew Weier O'Phinney, lead developer on the Zend Framework project, has written up a new post for his site showing how to use anonymous classes to write middleware for your applications (several frameworks support the concept of middleware these days).

I faced an interesting question recently with regards to middleware: What happens when we go from a convention-based to a contract-based approach when programming?

Convention-based approaches usually allow for duck-typing; with middleware, it means you can write PHP callables - usually closures - and just expect them to work.

Contract-based approaches use interfaces. I think you can see where this is going.

He starts off looking at some of the currently popular methods for creating middleware basic them off of either the PSR-7 standard or the proposed PSR-15 HTTP middleware, each with code examples to illustrate. The post then gets to the point with a look at anonymous class-based middleware and some of the advantages they provide. He refactors both a PSR-7 middleware and a closure-based middleware over to PSR-15 using this method.