PHP Internals News: Episode 81: noreturn type – Derick Rethans

PHP Internals News: Episode 81: noreturn type

In this episode of “PHP Internals News” I chat with Matthew Brown (Twitter) and Ondřej Mirtes (Twitter) about the “noreturn type” RFC.

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:15

Hi I’m Derick. Welcome to PHP internals news, a podcast dedicated to explaining the latest developments in the PHP language. This is episode 81. Today I’m talking with Matt Brown, the author of Psalm and Ondřej Mirtes, the author of PHPStan, about an RFC that I propose to alter the noreturn type. Matt, would you please introduce yourself?

Matthew Brown 0:37

Hi, I’m Matthew Brown, Matt, I live in New York, I’m from the UK. I work at a company called Vimeo, and I’ve been working with for the past six years on a static analysis tool called Psalm, which is my primary entry into the PHP world, and I, along with Ondřej authored this noreturn RFC.

Derick Rethans 1:01

Alright Ondřej, would you please introduce yourself too?

Ondřej Mirtes 1:04

Okay, I’m Ondřej Mirtes, and I’m from the Czech Republic, and I currently live in Prague or on the suburbs of Prague, and I’ve been developing software in PHP for about 15 years now. I’ve also been speaking at international conferences for the past five years before the world was still alright. In 2016, I released PHPStan, open source static analyser focused on finding bugs in PHP code basis. And somehow, I found a way to make a living doing that so now I’m full time open source developer, and also father to two little boys.

Derick Rethans 1:35

Glad to have you both here. We’re talking about something that clearly is going to play together with static analysers. Hence, I found this quite interesting to see to have two competitive projects, or are the competitive, or are the cooperative.

Matthew Brown 1:56

I think half and half.

Derick Rethans 1:57

Half and half. Okay.

Ondřej Mirtes 1:59

Competition is a weird concept in open source where everything is released for free here that

Derick Rethans 2:04

That’s certainly true, but you said you’re making your living out of it now so maybe there was something going on that I’m not aware of. In any case, we should probably chat about the RFC itself. What’s the reason why you’re wanting to add to the noreturn type?

Ondřej Mirtes 2:18

I’m going to start with a little bit of a detour, because in recent PHP development, it has been a trend to add the abilities to express various types natively, in in the language syntax. These types, always originally appeared in PHP docs for documentation reasons, IDE auto completion, and later were also used, and were being related with static analysis tools. This trend of moving PHP doc types tonight this type started probably with PHP seven that added scalar type hint. PHP 7.1 added void, and nullable type hints, 7.2 added object type, 7.4 added typed properties. And finally, PHP, 8.0 added union types. Right now to PHP community, most likely waits for someone to implement the generics and intersection types, which are also widely adopted in PHP docs, but there’s also a noreturn, a little bit more subtle concept, that would also benefit from being in the language. It marks functions and methods that always throw an exception, or always exit, or ent

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

Grauphel: Seeking new maintainer or funding – Christian Weiske

In 2014 I wrote grauphel, a owncloud/Nextcloud extension that allows you to synchronize notes between Tomboy (Linux, Windows), Tomdroid (Android) and Conboy (Nokia N900 – Maemo).

I personally do not use grauphel anymore and thus have no reason to maintain it any longer. For each Nextcloud release it must be tested, updated and re-released. Big changes are necessary to make it compatible with Nextcloud 21 as well.

The last real changes to grauphel were done in 2018 (version 0.7.0), and since then the changes were only to make it compatible with Nextcloud 15…20. The application itself is complete since 4 years, but unfortunately the foundations are constantly moving.

The original grauphel was a standalone application, but I converted it to a owncloud/nextcloud extension so that I can rely on its login and user management. From today’s perspective this was a mistake; a standalone version would still work today and not require unnecessary maintenance.

I’d like to hand grauphel over to a new maintainer that keeps it compatible with the latest Nextcloud versions.

Alternatively, I could make a standalone version of grauphel that works without Nextcloud if I get money to work on this task – 1000€.

Please write a comment in the issue on github if you’d like to take over the project, or how much you’re willing to contribute to the standalone version’s fund.

Ketting 7 released – Evert Pot

We just released version 7 of Ketting. Ketting is a generic HATEOAS
client for Javascript.

A whole bunch of features have been added since September. We’ve been
testing Ketting 7 in beta since January, so I’m excited to get this out
the door.

I’ve been working on this project since 2016. Normally, I would expect a
project like this to get a little stale. For me personally, the opposite
has been true and using Ketting (especially with React) is starting to feel
a bit like a paradigm shift.

Read on to see what’s new!

What is Ketting?

In short: Ketting is a generic REST client for Javascript. You can use it for
pushing JSON objects via HTTP, but the richer your API is in terms of best
practices and standard formats, the more it can automatically do for you.

It has support for Hypermedia formats such as HAL, Siren, Collection+JSON,
JSON:API and can even understand and follow links from html.

In the past it was not uncommon to hear that HATEOAS is lacking a good generic
client. If you are a Javascript/Typescript user this is no longer true.

More information can be found on the Github page.

What’s new?

Better HAL-Forms support

HAL-Forms is an extension of HAL, and adds support for ‘actions’ or
‘forms’, similar to what the <form> tag is to html.

Since the start of the year HAL-Forms has seen major updates, which was a
collaborative effort by several people from projects in the HAL community
(including Spring HATEOAS and yours truly) and lead by it’s author
Mike Amudsen.

Spring HATEOAS released its HAL-Forms updates in version 1.3 M2 (unclear
if this is a stable release or not), and Ketting follows today.

Major new features in HAL-Forms include:

  • Support for lookups
    • Example use-case is rendering dropdowns/comboboxes.
    • The list of possible options can either be provided in-line or via an
      external resource.
    • JSON and text/csv is support for external resources.
  • Support for most of the html5 input types, such as checkbox, color,
    tel, email, textarea, etc.
  • Support for many of the field attributes that also exist in html5 form
    fields, such as placeholder, min, max, step, cols, rows, and
  • Support for a form target. Previously this could also be supplied via
    the URI.
  • Support for multiple forms per document.

React bindings: <RequireLogin>

(note: all of the new react-ketting features were backported to Ketting 6)

react-ketting now has a RequireLogin component, that can be use to handle
the OAuth2 authorization_code flow in React applications.

Example usage:

function MyApp() { return <RequireLogin clientId="my-oauth2-client-id" authorizeEndpoint="https

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

Bedrock for modern WordPress development –

WordPress is the legacy content management system. It’s remained tremendously popular since its release in 2003 for the power it gives users to quickly put together a website with tools that offer them real, intuitive control over their content. That popularity has both inspired and depended upon constant modernization efforts by WordPress fans. The latest project to keep the classic CMS clicking two decades after its birth is Bedrock, an effort to turn WordPress into a Twelve-Factor app by the folks at Roots.

Xdebug Update: March 2021 – Derick Rethans

Xdebug Update: March 2021

Another monthly update where I explain what happened with Xdebug development in this past month. These will be published on the first Tuesday 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 91% towards my $1,000 per month goal. If you are leading a team or company, then it is also possible to support Xdebug through a subscription.

In March, I worked on Xdebug for about 28 hours, with funding being around 32 hours.

Xdebug 3.1

I started working on the Xdebug 3.1 tasks, and so far I have mostly been working on making sure that Xdebug continues to compile with PHP 8, and on improvements to xdebug_info(). It now also includes whether a debug connection was successful, which IP address it connected to, and whether some protocol features are enabled.

I have also started triaging really old bug reports, and will close them if no extra information is provided. This should cut down on my “open issues” queue.

Xdebug Cloud

Xdebug Cloud is continuing to operate as Beta release, and provides an easy way to debug your PHP applications with Xdebug, without having to deal with complexities with regards to networking.

Packages start at £49/month, and revenue will also be used to further the development of Xdebug.

If you want to be kept up to date with Xdebug Cloud, please sign up to the mailinglist, which I will use to send out an update not more than once a month.

PHP Internals News: Episode 80: Static Variables in Inherited Methods – Derick Rethans

PHP Internals News: Episode 80: Static Variables in Inherited Methods

In this episode of “PHP Internals News” I chat with Nikita Popov (Twitter, GitHub, Website) about the “Static Variables in Inherited Methods” RFC.

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 explain the latest developments in the PHP language. This is episode 80. In this episode I speak with Nikita Popov again about another RFC that he’s proposing. Nikita, how are you doing today?

Nikita Popov 0:30

I’m still doing fine.

Derick Rethans 0:33

Well, that is glad to hear. So the reason why you saying, I’m still doing fine, is of course because we basically recording two podcast episodes just behind each other.

Nikita Popov 0:41

That’s true.

Derick Rethans 0:42

If you’d be doing fine 30 minutes ago and bad now, something bad must have happened and that is of course no fun. In any case, shall we take the second RFC then, which is titled static variables in inherited methods. Can you explain what is RFC is meant to improve?

Nikita Popov 1:00

I’m not sure what this meant to improve, it’s more like trying to fix a bug, I will say. This is a really, like, technical RFC for an edge case of an edge case, so I should say first, when I’m saying static variables, I’m not talking about static properties, which is what most people use, but static variables inside functions. What static variables do unlike normal variables, is that they persist across function calls. For example, you can have a counter static $i equals zero, and then increment it, and then each time we call the function, it gets incremented each time and the value from the previous call is retained. So that’s just the context of what we’re talking about.

Derick Rethans 1:43

Why would people make use of static variables?

Nikita Popov 1:46

I think one of the most common use cases is memoization.

Derick Rethans 1:50

Can you explain what that is?

Nikita Popov 1:51

If you have a function that that computes some kind of expensive result, but which is always the same, then you can compute it only once and store it inside the static variable, and then return it. Maybe possibly keyed by by the function arguments, but that’s the general idea. And this also works if it’s a free standing function. So if it’s not in the method where you could store state inside the static property or similar, but also works inside a non method function.

Derick Rethans 2:22

The keyword here in his RFC’s title is inherited methods, I suppose. What happens currently there?

Nikita Popov 2:29

There are a couple of issues in that area. The key part is first: How do static variables interact with methods at all? And the second part is how it interacts with inheritance. So first if you have an instance method, with a static variable, then some people expect that actually each object instance gets a separate static variable. This is not the case. The static variables are really bound to functions or methods, they do not depend on the object instanc

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