PHP 8.1.0 Alpha 2 available for testing – PHP: Hypertext Preprocessor

The PHP team is pleased to announce the second testing release of PHP 8.1.0, Alpha 2. This continues the PHP 8.1 release cycle, the rough outline of which is specified in the PHP Wiki.For source downloads of PHP 8.1.0 Alpha 2 please visit the download page.Please carefully test this version and report any issues found in the bug reporting system.Please DO NOT use this version in production, it is an early test version.For more information on the new features and other changes, you can read the NEWS file, or the UPGRADING file for a complete list of upgrading notes. These files can also be found in the release archive.The next release will be Alpha 3, planned for 8 Jul 2021.The signatures for the release can be found in the manifest or on the QA site.Thank you for helping us make PHP better.

The case for partials and pipes in PHP – Larry Garfield

The case for partials and pipes in PHP

The Partial Function Application RFC is currently in voting, and right now it’s a close vote to the negative. I wanted to take this opportunity to try and make the broader case for partial application and for its related RFC, the pipe operator, in a way that is more appropriate for a blog post than the RFC body (which is, by design, more concerned with the finer details of “what”).

The main pushback on the RFC so far is that the benefits don’t outweigh the cost of yet-more-syntax in the language. Which is a fair position to hold, albeit one I hope to convince you is incorrect. That is, I believe the benefits vastly outweigh the syntax and implementation cost.

Continue reading this post on PeakD.

Larry
23 June 2021 – 3:07pm

The case for partials and pipes in PHP – larry@garfieldtech.com

The case for partials and pipes in PHP

The Partial Function Application RFC is currently in voting, and right now it’s a close vote to the negative. I wanted to take this opportunity to try and make the broader case for partial application and for its related RFC, the pipe operator, in a way that is more appropriate for a blog post than the RFC body (which is, by design, more concerned with the finer details of “what”).

The main pushback on the RFC so far is that the benefits don’t outweigh the cost of yet-more-syntax in the language. Which is a fair position to hold, albeit one I hope to convince you is incorrect. That is, I believe the benefits vastly outweigh the syntax and implementation cost.

Continue reading this post on PeakD.

Larry
23 June 2021 – 3:07pm

PHP Internals News: Episode 89: Partial Function Applications – Derick Rethans

PHP Internals News: Episode 89: Partial Function Applications

In this episode of “PHP Internals News” I chat with Larry Garfield (Twitter) and Joe Watkins (Twitter, GitHub, Blog about the “Partial Function Applications” 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 89. Today I’m talking with Larry Garfield and Joe Watkins about a partial function application RFC that they’re proposing with Paul Crevela and Levi Morrison. Larry, would you please introduce yourself?

Larry Garfield 0:36

Hello World. I’m Larry Garfield or Crell on most social medias. I’m a staff engineer for Typo3 the CMS. And I’ve been getting more involved in internals these days, mostly as a general nudge and project manager.

Derick Rethans 0:52

And hello, Joe, would you please introduce yourself as well?

Joe Watkins 0:55

Hi, I’m Joe, or Krakjoe, I do various PHP stuff. That’s all there is to say about that really.

Derick Rethans 1:02

I think you do quite a bit more than just a little bit. In any case, I think for this RFC, you, you wrote the implementation of it, whereas Larry, as he said, did some of the project management, I’m sure there’s more to it than I’ve just paraphrased in a single sentence. But can one of you explain in one sentence, or if you must, maybe two or three, what partial function applications, or I hope for short, partials are?

Larry Garfield 1:27

Partial function application, in the broadest sense, is taking a function that has some number of parameters, and making a new function that pre fills some of those parameters. So if you have a function that takes four parameters, or four arguments, you can produce a new function that takes two arguments. And those other two you’ve already provided a value for in advance.

Derick Rethans 1:54

Okay, I feel we’ll get into the details in a moment. But what are its main benefits of doing this? What would you use this for?

Larry Garfield 2:01

Oh, there’s a couple of places that you can use partial application. It is what got me interested. It’s very common in functional programming. But it’s also really helpful when you want to, you have a function that like, let’s say, string replace takes three arguments, two of which are instructions for what to replace, and one of which is the thing in which you want to replace. If you want to reuse that a bunch of times, you could build an object and pass in constructor values and save those and then call a function. Or you can just partially apply string replace with the things to search for, and the things to replace with and get back a function that takes one argument and will do that replacement on it. And you can then reuse that over and over again. There are a lot of cases like that, usually use in combination with functions that wants a callback. And that callback takes one argument. So array map or array filter are cases where very often you want to give it a function that takes one argument, you have a function that takes three arguments, you want to fill in those first ones first, and then pass the result that only takes one argument to array map or a filter, or whatever. So that’s the one of the common use cases for it.

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

Release of the Rector book – Matthias Noback

TLDR;

Rector – The Power of Automated Refactoring is now 100% completed

Book cover

Tomas Votruba and I first met a couple of years ago at one of my favorite conferences; the Dutch PHP Conference in Amsterdam (so actually, we’re very close to our anniversary, Tomas!). He presented Rector there and it was really inspiring. A year later I was working on a legacy migration problem: our team wanted to migrate from Doctrine ORM to “ORM-less”, with handwritten mapping code, etc. I first tried Laminas Code, a code generation tool, but it lacked many features, and also the precision that I needed. Suddenly I recalled Rector, and decided to give it a try. After some experimenting, everything worked and I learned that this tool really is amazingly powerful!

Thank you, Tomas

I asked Tomas if he would like to write a book together, about Rector, combining the perspective of a developer who needs to learn how to use and extend Rector, with the perspective of the creator who has a vision for the project. This turned out to be a very fruitful collaboration. To be extremely honest, in the beginning of the project I was really annoyed by Tomas’ contributions. As an example, this guy put all of the value object classes in a namespace called ValueObjects. I had never encountered anything like that. He also added all kinds of PHPStan rules that would throw errors in my face whenever I tried to commit anything. At first I was like: that is not how writing a book works, Tomas. You’re treating it as a software project. I want to have freedom. I want to treat it like art.

In the end, I realized we were optimizing for different things. He focused on:

  • Achieving the simplest possible setup for service container configuration.
  • Never having to remember any special rule: a failing build should remind you of your mistakes.
  • Maximum maintainability in the long run. This book needs to be useful not only this year, but during the life span of the project itself.

These are very valuable principles, and from this place I’d like to thank Tomas for leading by example here. I’ll never forget this, and will make it part of every future project (books and software projects alike). Thanks to this approach, every code sample is analyzed for issues, automatically formatted, and every code sample can be automatically refactored with Rector. When we need to, we can even upgrade the code base to a new PHP version. In fact, we could even decide to downgrade it!

Rector is better because of this book

While writing I often encountered a weird problem. Sometimes it turned out to be bug in Rector, sometimes an edge case that would be solved by a feature that was already on the roadmap (like migrating Rector to use static reflection). In all cases, Tomas was able to improve Rector, making the learning experience for news users much smoother, and more enjoyable.

You’ll be a better developer because of this book

Rector is a fascinating tool, but before you can effectively extend it for your own code transformation needs, you have to learn about some other related topics, like tokenizing, parsing, the Abstract Syntax Tree, node visitors, and so on. This book aims to provide a good introduction to all these topics, making you a better developer anyway, even if you’d never actually use Rector.

Conclusion

In conclusion: buy this book. It’s now 100% complete. It’ll teach you a lot about PHP as a language, how to improve legacy projects without wasting development time, and even about test-driven development.

PHP 8.1.0 Alpha 1 available for testing – PHP: Hypertext Preprocessor

The PHP team is pleased to announce the first testing release of PHP 8.1.0, Alpha 1. This starts the PHP 8.1 release cycle, the rough outline of which is specified in the PHP Wiki.For source downloads of PHP 8.1.0 Alpha 1 please visit the download page.Please carefully test this version and report any issues found in the bug reporting system.Please DO NOT use this version in production, it is an early test version.For more information on the new features and other changes, you can read the NEWS file, or the UPGRADING file for a complete list of upgrading notes. These files can also be found in the release archive.The next release will be Alpha 2, planned for 24 Jun 2021.The signatures for the release can be found in the manifest or on the QA site.Thank you for helping us make PHP better.

Xdebug Update: May 2021 – Derick Rethans

Xdebug Update: May 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 51% towards my $2,000 per month goal. If you are leading a team or company, then it is also possible to support Xdebug through a subscription.

In May, I worked on Xdebug for about 25 hours, with funding being around 30 hours.

Xdebug 3.1

I’m continuing to track PHP 8.1’s development and have now added support for Fibers in the debugger. I have not spend time adding support for the new Enum yet, but that should happen soon. I suspect that more work to make Xdebug PHP 8.1 compatible is going to be required in the future too.

After meeting with a developer of the PHP Debug Adapter for Visual Studio Code, I’ve started to work on some of the things that he raised. For example, there is now a new protocol feature that makes Xdebug include information about the breakpoint that was hit.

He also raised a bug where Xdebug truncates log messages and with UNC paths. I have fixed the first one, but the second one requires more investigation and a “clever solution”.

Xdebug Videos

I have published another videos on how to use Xdebug on my YouTube channel.

This one deals about Debugging the Symfony Demo App in Docker with VS Code.

I have been working on another animated video where I explain how to activate Xdebug’s features with triggers and settings. This should come out in the next few weeks.

If you would like to see a 5 to 10 minute long video on another specific topic, feel free to email me at derick@xdebug.org.

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 88: Pure Intersection Types – Derick Rethans

PHP Internals News: Episode 88: Pure Intersection Types

In this episode of “PHP Internals News” I talk with George Peter Banyard (Website, Twitter, GitHub, GitLab) about the “Pure Intersection Types” RFC that he has proposed.

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

Welcome to PHP internals news, a podcast dedicated to explaining the latest developments in the PHP language. This is Episode 88. Today I’m talking with George Peter Banyard about pure intersection types. George, could you please introduce yourself?

George Peter Banyard 0:30

Hello, my name is George Peter Banyard. I work on PHP code development in my free time. And on the PHP Docs.

Derick Rethans 0:36

This RFC is about intersection types. What are intersection types?

George Peter Banyard 0:40

I think the easiest way to explain intersection types is to use something which we already have, which are union types. So union types tells you I want X or Y, whereas intersection types tell you that I want X and Y to be true at the same time. The easiest example I can come up with is a traversable that you want to be countable as well. So traversable and countable. Currently, you can do intersection types in very hacky ways. So you can either create a new interface which extends both traversable and countable, but then all the classes that you want to be using this fashion, you need to make them implement the interface, which might not be possible if you using a library or other things like that. The other very hacky way of doing it is using reference and typed properties. You assign two typed properties by reference, one being traversable, one being countable, and then your actual property, you type alias reference it, with both of these properties. And then my PHP will check: does the property respect type A those reference? If yes, move to the next one. It doesn’t respect type B, which basically gives you intersection types.

Derick Rethans 1:44

Yeah, I saw that in the RFC. And I was wondering like, well, people actually do that?

George Peter Banyard 1:49

The only reason I know that is because of Nikita’s slide.

Derick Rethans 1:51

The thing is, if it is possible, people will do it, right. And that’s how that works.

George Peter Banyard 1:56

Yeah, most of the times.

Derick Rethans 1:57

The RFC isn’t actually called intersection types. It’s called pure intersection types. What does the word pure do here?

George Peter Banyard 2:05

So the word pure here is not very semantic. But it’s more that you cannot mix union types and intersection types together. The reasons for it are mostly technical. One reason is how do you mix and match intersection types and union types? One way is to have like union types take precedence over intersection types, but some people don’t like that and want to explicit it grouping all the time. So you need to do parentheses, A intersection B, close parentheses, pipe for the union, and then the other type. But I think the main reason is mostly the variance, like the variance checks for inheritance are already kind of complicated and kind of mind boggling.

Derick Rethans 2:44

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

PHP Internals News: Episode 87: Deprecating Ticks – Derick Rethans

PHP Internals News: Episode 87: Deprecating Ticks

In this episode of “PHP Internals News” I chat with Nikita Popov (Twitter, GitHub, Website) about the “Deprecating Ticks” 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 87. Today I’m talking with Nikita Popov about a much smaller RFC this time: Deprecating Ticks. Nikita, would you please introduce yourself.

Nikita Popov 0:34

Hi Derick, I’m Nikita, and I’m working on PHP core development on behalf of JetBrains.

Derick Rethans 0:40

Let’s jump straight into what this RFC is about, and that’s the word ticks. What are ticks?

Nikita Popov 0:46

Ticks are a declare directive,. You write declare ticks equals one at the top of your file, and then PHP we’ll call a tick function after every statement execution. Or if you write ticks equals two, then as we’ll call it the function after every two statement executions.

Derick Rethans 1:05

Do you have to specify which function that calls?

Nikita Popov 1:08

Of course, so there is also a register tick function and unregister tick function and that’s how you specify the function that should be called rather the functions.

Derick Rethans 1:17

How does this work, historically, because the RFC talks about the change being made in PHP seven?

Nikita Popov 1:22

Technically ticks work by introducing an opcode after every statement that calls the tick function depending on current count. The difference that was introduced in PHP seven is to what the tick declaration applies. The way PHP language semantics are supposed to work, is that declare directives are always local. The same way that strict types, only applies to a single file, ticks should also only apply to a single file. Prior to PHP seven, it didn’t work out way. So if you had declare ticks, somewhere in your file, it would just enable ticks from that point forward. If you included the different file or even if the autoloader was triggered and included a different file that one would also make use of ticks. That was fixed in PHP seven, so now it is actually file local, but that also means that the ticks functionality at that point behaviour became, like, not very useful. Because usually if you want to use tics you actually want them to apply it to your whole codebase. There are ways around that. I’m afraid to say that people have approached me after this RFC and told me that they actually do that. The way around that is to register a stream wrapper. It’s possible in PHP to unregister the file stream wrapper and register your own one, and then it’s possible to intercept all the file includes and rewrite the file contents to include the declare ticks at the top of the file. I do use that general mechanism for real things in other places, but apparently people actually use that to like instrument, a whole application with ticks, and essentially restore the behaviour we had in PHP 5.

Derick Rethans 3:03

What was the intended use case for ticks to begin with?

Nikita Popov 3:07

Well I’m not sure what was the intended use case, but at least it was the main use case, and that’s signal handl

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

Good technical writing is hard – larry@garfieldtech.com

Good technical writing is hard

A few days ago, I randomly tossed this out on Twitter without context:

Technical writing requires assuming the reader is simultaneously highly intelligent and utterly ignorant, without making them feel like you think they’re utterly ignorant.

That shit is hard, yo.

Someone asked for ideas on how to achieve that goal, and it seemed like a topic worthy of discussion so here we are.

Technical writing is not for Dummies

I would expand the statement above a bit, actually. Good technical writing requires:

Larry
31 May 2021 – 8:07pm