Oh Dear is the all-in-one monitoring tool for your entire website. We monitor uptime, SSL certificates, broken links, scheduled tasks and more. You'll get a notifications for us when something's wrong. All that paired with a developer friendly API and kick-ass documentation. O, and you'll also be able to create a public status page under a minute. Start monitoring using our free trial now.

On using arrow functions in PHP 7.4

Original – by Freek Van der Herten – 3 minute read

In PHP 7.4 a widely requested feature landed: arrow function. In this blogpost I'd like to show you how I like to use them.

Let's start with an example from the Oh Dear codebase I tweeted out a few days ago.

In Laravel 6 and PHP 7.3 you could do this:

public static function boot()
{
    static::boot();

    static::creating(
        function (Team $team) {
            return $team->webhook_signing_secret = Str::random(32);
        }
    );
}

In Laravel 7 and PHP 7.4 you can rewrite it to this:

public static function booted()
{
   static::creating(fn (Team $team) => $team->webhook_signing_secret = Str::random(32));
}

In the code snippet above, a short closure is used. It's a bit beyond the scope of this post, but in Laravel 7, the booted lifecycle method was introduced, which will, unsuprisingly, be called we the model has booted. Using that method, you can lose the static::boot(); call from the initial code snippet.

A lot of people seemed to like it. Some didn't, and that's ok. When introducing new syntax, I don't think there's a single thing where all programmars will agree on. A comment I agree on however, is the line length. Luckily this can be easily fixed by moving the closure itself to it's own line.

public static function booted()
{
   static::creating(
      fn (Team $team) => $team->webhook_signing_secret = Str::random(32)
   );
}

To make the line length shorter, you could opt to remove the typehint. You could even rename the $team variable to $t, this is pretty common practice in the JavaScript. Personally I love typehints and full variable names, so personally I stick to the code snippet above.

I think it would be silly to blindly switch to short closures wherever it is technically possible. The question you should keep in mind when converting a closure to a short one is: "Does this make the code more readable?". Of course, the answer is subjective. When in doubt, I recommend just asking your team members, they're the ones that will have to read your code too.

If you use PhpStorm you can easily switch between a normal and a short closurse, so you can quickly get a feel of how it reads.

convert.

Let's end by taking a look at an example where I think short closures really shine: in collection chains (thanks for the example, Liam).

Stay up to date with all things Laravel, PHP, and JavaScript.

You can follow me on these platforms:

On all these platforms, regularly share programming tips, and what I myself have learned in ongoing projects.

Every month I send out a newsletter containing lots of interesting stuff for the modern PHP developer.

Expect quick tips & tricks, interesting tutorials, opinions and packages. Because I work with Laravel every day there is an emphasis on that framework.

Rest assured that I will only use your email address to send you the newsletter and will not use it for any other purposes.

Comments

What are your thoughts on "On using arrow functions in PHP 7.4"?

Comments powered by Laravel Comments
Want to join the conversation? Log in or create an account to post a comment.