PHP Internals News: Episode 82: Auto-Capturing Multi-Statement Closures – Derick Rethans

PHP Internals News: Episode 82: Auto-Capturing Multi-Statement Closures

In this episode of “PHP Internals News” I chat with Larry Garfield (Twitter) and Nuno Maduro (Twitter, GitHub, Blog) about the “Auto-Capturing Multi-Statement Closures” RFC.

The RSS feed for this podcast is https://derickrethans.nl/feed-phpinternalsnews.xml, you can download this episode’s MP3 file, and it’s available on Spotify and iTunes. There is a dedicated website: https://phpinternals.news

Transcript

Derick Rethans 0:14

Hi, I’m Derick. Welcome to PHP internals news, a podcast dedicated to explaining the latest developments in the PHP language. This is episode 82. Today I’m talking with Nuno Maduro and Larry Garfield. Nuno, would you please introduce yourself?

Nuno Maduro 0:30

Hi PHP developers. My name is Nuno Maduro, and I am software engineer at Laravel, the company that owns the Laravel framework, and I have created multiple open source projects for the PHP community, such as Pest PHP, Laravel zero, collusion and more.

Derick Rethans 0:48

Alright, and Larry, could you please follow up on that.

Larry Garfield 0:51

Hello world, so I’m Larry Garfield. You may know me from several past podcasts here, various work in the PHP fig, and all around gadfly and nudge of the PHP community.

Derick Rethans 1:03

Good to have you again Larry and good to have you here today, Nuno. The RFC, that we’re talking about here today is to do with closures, and the title of the RFC is auto capturing multi statement closures, which is quite a mouthful. Can one of you explain what this RFC is about?

Nuno Maduro 1:20

As you said, the RFC title is indeed auto capturing multi statement closures. But to make it simple, we are really talking about adding multi line support to the one line arrow functions that got introduced it, in PHP 7.4. Now, this new multi line arrow functions have exactly the same features as the one line arrow functions, so they are anonymous, locally available functions; variables are auto captured lexically meaning that you don’t actually need the use keyword to manually import the use of variables, they just get auto captured from the outer scope. And the only difference really is one line arrow functions have a body with a single expression. This RFC actually allows you to use a full statement list that possibly ends with a return.

Derick Rethans 2:18

Excellent, what the syntax that you’re proposing here?

Nuno Maduro 2:22

Well, as you may know, one line arrow functions have the syntax, which is fn, parameter list, and then that arrow expression thing, and this new RFC proposes that, optionally, developers can pass a curly brackets with statements, instead of having that arrow expression syntax. Now, this curly brackets with statements, simply denotes a statement list that potentially ends with a return. Concerning the Auto Capture syntax, we will be just reusing the Auto Capture syntax and feature that already exists on one line arrow functions, meaning that you don’t need the use keyword to manually import variables. And of course, the syntax itself, in the in the feature, works the exactly same way. Concerning the syntax, it’s also important to mention that this RFC was done in combination with the short functions RFC from Larry, but I think I’m going to let Larry speak about that later on this episode.

Derick Rethans 3:26

What’s the main idea behind wanting to introduce this auto capture m

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

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 https://derickrethans.nl/feed-phpinternalsnews.xml, you can download this episode’s MP3 file, and it’s available on Spotify and iTunes. There is a dedicated website: https://phpinternals.news

Transcript

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
    others.
  • 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 – platform.sh

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 https://derickrethans.nl/feed-phpinternalsnews.xml, you can download this episode’s MP3 file, and it’s available on Spotify and iTunes. There is a dedicated website: https://phpinternals.news

Transcript

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)

Tinker-like REPL for Mezzio – Matthew Weier O’Phinney

Today in the Laminas Slack, somebody asked if there was an equivalent to Laravel’s Tinker REPL.
The short answer is “no”, but I had a suggestion for them.

PHP REPL

The first part of my answer to the question was suggesting they use the PHP REPL.

PHP has had a REPL since version 5.1.0, which you can invoke using php -a.
Once you’ve started, you can do anything you’d normally do in PHP, including such things as including files, declaring namespaces, declaring classes, etc.

I’ve often wanted to test how classes work, or run one-off jobs without writing a script.
To accomplish these tasks, I’ll include the autoloader installed by Composer:

$ php -a
php > include './vendor/autoload.php';

Once I’ve done that, I can reference any classes, functions, and constants autoloaded by Composer, as well as anything PHP exposes.

Mezzio container

The Mezzio skeleton sets up a few files in its config/ subdirectory that give us a number of ready-to use artifacts.

The first is config/config.php, which aggregates and returns all application configuration, including from config providers as well as local autoloaded configuration files (those in config/autload/).
From the REPL, you can dump this information directly if you want:

$ php -a
php > include './vendor/autoload.php'; // we need autoloading for most config providers
php > $config = include './config/config.php';
php > var_export($config);

The second, and more important to this exercise, is config/container.php.
This file autoloads, configures, and returns the PSR-11 DI container defined in the application.
By using this approach, we can keep Mezzio agnostic of the specific container used, and leave it to that file to properly instantiate and configure it for us.
We provide out-of-the-box versions of that file for a number of containers, and have a specification for dependency configuration that we recommend to ensure that dependency configuration provided by third-party packages can be detected and utilized.

Because this is just a PHP file, and returns the PSR-11 container, we can include that and capture it to a variable in the REPL:

$ php -a
php > include './vendor/autoload.php';
php > $container = include './config/container.php';

From there, you can then pull any configured services, including the configuration, and start interacting with them:

php > include './vendor/autoload.php';
php > $container = include './config/container.php';
php > $config = $container->get('config');
php > echo $config['debug'] ? 'In debug mode' : 'In production mode';
php > $httpClient = $container->get(Http\Adapter\Guzzle7\Client::class);

Fin

While not quite as powerful as Tinker, the PHP REPL, coupled with Composer autoloading and a configured PSR-11 container, is a fantastic tool for interacting with your project.
I can definitely recommend this as a way to play with and experiment with your application code!

mwop Tinker-like REPL for Mezzio was originally published on https://mwop.net by .

PHP releases on hold – PHP: Hypertext Preprocessor

As announced on the php.internals mailing list, a pair of malicious commits were made in the PHP source code repository over the weekend. These commits were immediately noticed and reverted, and thus never reached end users. The investigation into the root cause and exact scope of the compromise is still ongoing, therefore releases will be put on hold for two weeks assuming no further issues are discovered. Thank you for bearing with us while we endeavor to ensure that PHP is a stable and reliable platform for web development.