Interview with Matthias Noback – Voices of the ElePHPant

Cal Evans hosts his friend Matthias Noback as they talk about Domain Driven Design and Matthias’ new book “Recipes for Decoupling.

This episode is sponsored by
RingCentral Developers

The post Interview with Matthias Noback appeared first on Voices of the ElePHPant.

PHP Internals News: Episode 101: More Partially Supported Callable Deprecations – Derick Rethans

PHP Internals News: Episode 101: More Partially Supported Callable Deprecations

In this episode of “PHP Internals News” I talk with Juliette Reinders Folmer (Website, Twitter, GitHub) about the “More Partially Supported Callable Deprecations” RFC that she has proposed.

The RSS feed for this podcast is, you can download this episode’s MP3 file, and it’s available on Spotify and iTunes. There is a dedicated website:


Derick Rethans 0:14

Hi, I’m Derick. Welcome to PHP internals news, the podcast dedicated to explaining the latest developments in the PHP language. This is episode 101. Today I’m talking with Juliette Reinders Folmer, about the Expand Deprecation Notice Scope for Partially supported Callables RFC that she’s proposing. That’s quite a mouthful. I think you should shorten the title. Juliette, would you please introduce yourself?

Juliette Reinders Folmer 0:37

You’re starting with the hardest questions, because introducing myself is something I never know how to do. So let’s just say I’m a PHP developer and I work in open source, nearly all the time.

Derick Rethans 0:50

Mostly related to WordPress as far as I understand?

Juliette Reinders Folmer 0:52

Nope, mostly related to actually CLI tools. Things like PHP Unit polyfills. Things like PHP Code Sniffer, PHP parallel Lint. I spend the majority of my time on CLI tools, and only a small portion of my time consulting on the things for WordPress, like keeping that cross version compatible.

Derick Rethans 1:12

All right, very well. I actually did not know that. So I learned something new already.

Juliette Reinders Folmer 1:16

Yeah, but it’s nice. You give me the chance now to correct that image. Because I notice a lot of people see me in within the PHP world as the voice of WordPress and vice versa, by the way in WordPress world to see me as far as PHP. And in reality, I do completely different things. There is a perception bias there somewhere and which has slipped in.

Derick Rethans 1:38

It’s good to clear that up then.

Juliette Reinders Folmer 1:39

Yeah, thank you.

Derick Rethans 1:40

Let’s have a chat about the RFC itself then. What is the problem that is RFC is trying to solve?

Juliette Reinders Folmer 1:46

There was an RFC or 8.2 which has already been approved in October, which deprecates partially supported callables. Now for those people listening who do not know enough about that RFC, partially supported callables are callables which you can call via a function like call_user_func that which you can’t assign to variable and then call as a variable. Sometimes you can call them just by using the syntax which you used for defining the callable, so not as variable but as the actual literal.

Derick Rethans 2:20

And as an example here, that is, for example, static colon colon function name, for example.

Juliette Reinders Folmer 2:26

Absolutely, yeah.

Derick Rethans 2:27

Which you can use with call_user_func by having two array elements. You can call it with literal syntax, but you can’t assign it to a variable and then call it. Do I get that, right?

Juliette Re

Truncated by Planet PHP, read more at the original (another 21583 bytes)

Much ado about null – Larry Garfield

Much ado about null

Submitted by Larry on 13 May 2022 – 11:24am

null has a controversial history. It’s been called “the billion-dollar mistake” by its creator. Most languages implement null, but those few that do not (such as Rust) are generally lauded for their smart design by eliminating a class of errors entirely. Many developers (myself included) have argued that code that uses null or nullable parameters/returns is intrinsically a code smell to be avoided, while others (also myself included, naturally) have argued that is too draconian of a stance to take.

Anna Filina has a very good three-part series (properties, parameters, and returns) on how to avoid null in PHP generally. Alexis King has a related post (excuse the Haskell) on how to avoid needing edge cases like null in the first place.

However, I want to go a bit deeper and try to understand null from a different angle, and tease out the nuance of why one would really want to use it, and thus what we should be doing instead. To get there we’ll have to go through a tiny little bit of type theory, but it will be quick and painless, I swear.

Continue reading this post on PeakD.

Xdebug Update: April 2022 – Derick Rethans

Xdebug Update: April 2022

In this monthly update I explain what happened with Xdebug development in this past month. These are normally published on the first Tuesday on or after the 5th of each month.

Patreon and GitHub supporters will get it earlier, around the first of each month.

You can become a patron or support me through GitHub Sponsors. I am currently 46% towards my $2,500 per month goal. If you are leading a team or company, then it is also possible to support Xdebug through a subscription.

In April, I spend 29 hours on Xdebug, with 27 hours funded.

the original (another 1331 bytes)

TailwindCSS Tips – Matthew Weier O’Phinney

I’ve been dabbling in CSS my entire career.
In the early days, it was relatively simple, as our browsers were fairly limited.
But over the years, CSS has become more and more capable, allowing styles to target only tags with specific tag attributes, only apply at specific screen sizes, and even perform complex layouts using things like flexbox and grid.
I take a bit of time every now and then to understand these things… but since I don’t use CSS a ton, it’s hard to keep up.

As such, over the past decade, I’ve tended to use CSS frameworks, and generally Bootstrap.
Every couple years, a new major version is dropped, and I have to learn new structures and components, and struggle to get things to look the way I want.
Worse, when I use these frameworks, injecting custom CSS often means understanding how the framework is already styling components so I can ensure things don’t conflict.

The last couple years, I’ve been keeping an eye on TailwindCSS.
I’ve been a bit skeptical, as its declarative, utility-first approach looks a lot like doing CSS inside your html, which, honestly, feels off.
I’ve typically subscribed to the idea of semantic html, which advocates separating style from markup.
Having styles directly that mimic CSS directives associated with every tag feels like an unholy mix, and a far cry from semantic html.

And then there’s the hype.
The original author and project lead of Tailwind is a huge hype man, and hype tends to turn me off.
That’s on me, not them, but having been in the business for over two decades, I’m finding I’m more and more likely to discount hyped products and projects, because I’ve seen them come and go so frequently; there’s often an indirect relationship between the amount of hype and the long-term viability of a project.
I’ve also often observed that hype serves as a way for users to deflect reasonable critique, and the more vehement the user base, the less interested I am in engaging with them because of this.
Clearly, YMMV, but it was definitely something keeping me from really investigating Tailwind.

However, recently, in helping out the PHP Foundation, I volunteered to setup their static website, and the team requested using TailwindCSS, so I dove in.

And I discovered… I kind of love it.

This is one of those “I’ll be googling this in the future” posts.

How it works

I won’t go into how to get started with Tailwind; their docs do a great job of doing that for you.
However, I will give a quick overview of how things work, so you can see (a) where I’m coming from, and (b) what you’ll be doing when you start with Tailwind.

The way I’ve always learned to do CSS is to first write html, and then write CSS to style that html the way you want it to appear.

<div class="box"> <h2>Title</h2> <p>Some content</p>
</div> <style>
.box { margin: 0.5rem; background-color: #333333; border: #000000 padding: 0.5rem;
} .box h2 { background-color: #dedede; padding: 0.5rem; color: #111111; font-size: 2rem; min-width: max-content;
} .box p { padding: 0.5rem; font-size: 1.2rem; min-width: max-content;

Tailwind instead provides a ton of “utility” classes, targetting just about every CSS directive.
You then add these html classes to elements to style them:

<div class="m-2 p-2 bg-neutral-600 border-black"> <h2 class="min-w-full p-2 bg-neutral-300 text-4xl text-neutral-800">Title</h2> <p class="min-w-full p-2 text-xl">Some content</p>

Behind the scenes, you run the Tailwind CLI tool, and it analyzes your html to generate CSS for you.
You can even have it watching for filesystem changes to files you’re interested in (templates, JS scripts, etc.), and it will regenerate the CSS automatically.

Tip 1: Layers

Out of the box, Tailwind does a CSS reset that removes all styles.
This is great, because it means that any changes you make, you can anticipate exactly what will hapen.
It’s also a pain in the ass, because everything is unstyled: your headings look just like your paragraphs, your lists look just like your paragraphs, and there’s no way to tell where one paragraph ends and another begins.

So, the first thing you’ll want to do is define your base styles.
Tailwind has a very specific suggestion for where and how to do this: in the “base” layer.

Opening your site CSS file, you’ll see these directives when you begin:

@tailwind base;
@tailwind component

Truncated by Planet PHP, read more at the original (another 14308 bytes)

CI Pipelines for dockerized PHP Apps with Github & Gitlab [Tutorial Part 7] – Pascal Landau

In the seventh part of this tutorial series on developing PHP on Docker we will setup a CI
(Continuous Integration) pipeline to run code quality tools and tests on Github Actions and Gitlab