On using PSR abstractions – Matthias Noback

Several years ago, when the PHP-FIG (PHP Framework Interop Group) created its first PSRs (PHP Standard Recommendations) they started some big changes in the PHP ecosystem. The standard for class auto-loading was created to go hand-in-hand with the then new package manager Composer. PSRs for coding standards were defined, which I’m sure helped a lot of teams to leave coding standard discussions behind. The old tabs versus spaces debate was forever settled and the jokes about it now feel quite outdated.

Next up were the PSRs that aimed for the big goal: framework interoperability. It started with an easy one: PSR-3 for logging, but it took quite some time before the bigger ones were tackled, e.g. request/response interfaces, HTTP client and server middleware interfaces, service container interfaces, and several others. The idea, if I remember correctly, was that frameworks could provide implementation packages for the proposed interfaces. So you could eventually use the Symfony router, the Zend container, a Laravel security component, and so on.

I remember there were some troubles though. Some PSRs were abandoned, some may not have been developed to their full potential, and some may have been over-developed. I think it’s really hard to find common ground between framework implementations for all these abstractions, and to define abstractions in such a way that users and implementers can both be happy (see for example an interesting discussion by Anthony Ferrara about the HTTP middleware proposal and an older discussion about caching).

One of the concerns I personally had about PSR abstractions is that once you have a good abstraction, you don’t need multiple implementation packages. So why even bother creating a separate abstraction for others to use? Why not just create a single package that has both the implementation and the abstraction? It turns out, that doesn’t work. Why? Because package maintainers sometimes just abandon a package. And if that happens, the abstraction becomes useless too because it is inside that abandoned package. So developers do like to have a separate abstraction package that isn’t even tied to their favorite vendor.

(By the way, I think it’s strange for frameworks to have their own Interfaces or Contracts package for their abstractions. I bet there are 0 cases where someone using Laravel or Symfony keeps using its abstractions, but not its implementations. Anyway… If you have a different experience, or want to share your story about these packages, please submit a comment below!)

Is it safe to depend on PSR abstraction packages?

Back in 2013, Igor Wiedler made a lasting impression with their article about dependency responsibility. By now we all know that by installing a vendor package you can import bugs and security issues into your project. Another common concern is the stability of the package: is it going to be maintained for a long time? Are the maintainers going to change it often?

Yes, these concerns should be addressed, and I think in general they are not considered well enough. But we need to distinguish between different kinds of packages. Packages have a certain level of stability which is in part related to its abstractness and the number of dependencies it has (if you’re interested in this topic, check out my book “Principles of Package Design”).

The abstractness of a package is based on the number of interfaces versus the number of classes. Since abstract things are supposed to change less often than concrete things, and in fewer ways, an abstract package will be a stable package and it will be more reliable than less abstract, i.e. concrete packages (I think this is why frameworks provide those Interface or Contract packages: as an indication of their intended stability).

Another reason for a package to become stable is when it is used by many people. This is more of a social principle: the maintainers won’t change the package in drastic ways if that makes the users of the package angry. Of course, we have semantic versioning and backward compatibility promises for th

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

PHP Internals News: Episode 93: Never For Parameter Types – Derick Rethans

PHP Internals News: Episode 93: Never For Parameter Types

London, UK

Thursday, August 19th 2021, 09:21 BST

In this episode of “PHP Internals News” I chat with Jordan LeDoux (GitHub) about the “Never For Parameter Types” 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 93. It’s been quiet over the last month, so it didn’t really have a chance to talk about upcoming RFCs mostly because there were none. However, PHP eight one’s feature freeze has happened now, a new RFCs are being targeted for the next version of PHP eight two. Today I’m talking with Jordan LeDoux, about the Never For Parameter Types RFC, the first one targeting this upcoming PHP version. Jordan, would you please introduce yourself?
Jordan LeDoux 0:50: Certainly. And thanks for having me. My name is Jordan. I’ve worked as a developer for about 15 years now. Most of my career has been spent working in PHP. Although professionally, I’ve had experience working in C#, Python, TypeScript, mostly in the form of JavaScript, but a little bit of Node and, you know, a variety of other languages that I haven’t spent enough time in to really be proficient in any real way. But recently, I decided to do something that I have thought about doing for many years, but never actually jumped into which is exploring the PHP engine itself and how I could possibly contribute to it.
Derick Rethans 1:32: And here we are, but your first our thing.
Jordan LeDoux 1:35: Yeah, it’s exciting.
Derick Rethans 1:36: What is this RFC about, what does it propose?
Jordan LeDoux 1:39: Well, this RFC proposes allowing the never type, which was added in 8.1 as a return value, to parameters for functions and methods on objects. The main idea behind that is that when never was proposed as a return type, it was meant to signal that the function would never return. Not that it returns void, which of course, void signifies which is returning no value or returning, returning without any specified information. And never return signifies that the function will never return, which is a concept that exists in many other languages. And for that purpose in other languages, what’s usually used is something called a bottom type. And that’s what never ended up being. And I’m proposing that we extend the use of that bottom type to other areas where the type may be helpful.
Derick Rethans 2:38: So a bottom type, that might be a new term for many people, it will certainly for me when I looked at the never RFC for as return types. Can you sort of explain what a bottom type is, especially thinking about object oriented theory with something that we’d like to call the Liskov Substitution Principle? And also, how does it apply to argument types?
Jordan LeDoux 2:59: Let’s start with the Liskov Substitution. The general idea behind Liskov Substitution is that if A is a subtype of B, then anywhere that A exists, you should be able to substitute B. It has to do with when you have a class hierarchy in in an object oriented language, that that class hierarchy guarantees certain things about substitutionality, like whether or not something can be substituted for something else. That affects language design in ways that a lot of programmers are kind of intuitively familiar with, but maybe not familiar with the theory and the ideas behind it more concretely. But LSP is the principl

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

PHP 8.1.0 Beta 3 available for testing – PHP: Hypertext Preprocessor

The PHP team is pleased to announce the release of PHP 8.1.0, Beta 3. This is the third beta release, continuing 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, Beta 3 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 the first release candidate (RC 1), planned for 2 September 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.

Changelog generator for GitHub milestones – Rob Allen

For many years now, I’ve been using Matthew Weier O’Phinney’s changelog_generator script to generate an easy-to-read list of changes for a given milestone. Time has moved on; the Laminas project now uses Laminas Automatic Releases and Matthew hasn’t updated his script since 2013. Since PHP 8, warnings have started appear, so it’s clear updates were required. While I fully intend to see if I can use Automatic Releases on some projects, I have others where this is unlikely to happen and will continue to use changelog-generator.

Looking into it, I worked out that the warnings were from dependent packages. PHP has changed a bit since 2013. My first idea was to simply update to the latest Laminas versions of the dependencies, but I discovered that the Console and Http components are no longer actively maintained, so new components would be needed. I don’t particuarly want to have to do this all again in a few years time when the replacements that I pick don’t support PHP 8.4 or whatever, so I decided to remove the dependencies completely.

Looking at Console, I quickly realised that only one class was used by changelog-generator: Getopt, which worked fine under PHP 8. So, I copied that one class to src, changed the namespace and called it done. For Http, I wrote a new HttpClient class that only makes GET requests using PHP’s curl functions. I’m reasonably confident that the API to those functions won’t be changing signicantly.

While I was messing around, I also fixed a few bugs so that searching by title will look for closed milestones and it now lists the last 20 milestones if you don’t provide an argument. Just a couple of quality of life features to make make it easier for me to use.

My version is now up on Packagist if you need something like this. However, I strongly recommend looking at Laminas Automatic Releases as that automates all the work required for doing a release. If you just need a formatted list of closed issues though, grab this and see if it works for you.

Thoughts on dependencies

My general view is that if it’s not core to your application, then using a dependent package is the way forward. There’s rarely any benefit from spending time working on something that others have already built and to which you are not adding value. This is particularly true for applications where you are adding new features and have better things to do.

However, sometimes this isn’t the right choice. In this case, I need a very small subset of what a dependent package provides. I took the view that maintaining the dependencies would be more long-term work than writing the small components that I actually needed. Particularly, as this tool is stable.

Sometimes this is the right choice for a component in my big projects too.

Xdebug Update: July 2021 – Derick Rethans

Xdebug Update: July 2021

London, UK

Tuesday, August 10th 2021, 09:03 BST

In this monthly update 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 57% 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 July, I worked on Xdebug for about 50 hours, with funding being around 25 hours, which is only half.

PHP 8.1 Support

Now PHP 8.1’s feature freeze has happened, I am working on integrating the missing features into Xdebug. Last month I added support for PHP 8.1’s Enum type, but this required a little bit more work as it was emitting the same XML attribute more than once in some occasions. This came to the surface after adding support for Readonly Properties, another new feature in PHP 8.1.

IDEs have so far not yet been updated to make use of these new “facets” that Xdebug’s debugger emits. PhpStorm’s tracker has an issue for readonly as well as enums. The VS Code plugin’s tracker has issues for readonly and enums as well.

I also had to make some more tweaks with regard to PHP 8.1’s changes to internals, most notably related to static properties.

Xdebug 3.1

Beyond making sure that Xdebug 3.1 works will with PHP 8.1, and continues to work with PHP 7.2 through 8.0, I have been adding some new features too.

Xdebug 3.1 will no longer set either a timeout, or use Strict cookies to manage its debugging session through HTTP. Instead, it now uses a Lax and relies on the browser closing to clean out the cookie.

I have added a new function, xdebug_connect_to_client(). This function can be used to ask Xdebug to try to connect to a debugging client during a request. Normally, it only tries this at the start of a request. In some cases, with long running processes that run many worker jobs, it is sometimes useful to be able to open a debugging client at a later point, and then allow for Xdebug to try to connect to this debugging client. It will now do so if you call the xdebug_connect_to_client() function. This feature was requested by Tideways, a business supporter of Xdebug.

Now that PHP 8.1 has introduced a First Class Callable Syntax, I’ve updated Xdebug tracer and variable display routines to add information about which function/method a closure encapsulate as well. This information was previously missing. You can learn more about this PHP feature in the PHP Internals News episode First Class Callable Syntax.

Xdebug Cloud

To help with funding my work on Xdebug, I have a paid-for-service, called Xdebug Cloud.

Xdebug Cloud is the Proxy As A Service platform to allow for debugging in more scenarios, where it is hard, or impossible, to have Xdebug make a connection to the IDE. It is continuing to operate as Beta release.

Packages start at £49/month, and revenue will 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.

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

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

The PHP team is pleased to announce the first beta release of PHP 8.1.0, Beta 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, Beta 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 Beta 3, planned for Aug 19 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.

PHP Orchestration With ZendPHP Docker Images

In this blog, we take a deep dive into container orchestration with Docker and related technologies, as well as provide resources to get you started orchestrating your applications using ZendPHP.

PHP Internals News: Episode 92: First Class Callable Syntax – Derick Rethans

PHP Internals News: Episode 92: First Class Callable Syntax

London, UK

Thursday, July 22nd 2021, 09:20 BST

In this episode of “PHP Internals News” I chat with Nikita Popov (Twitter, GitHub, Website) about the “First Class Callable Syntax” RFC.

Transcript

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 92. Today I’m talking with Nikita Popov about a first class callable syntax RFC that he’s proposing together with Joe Watkins. Nikita, would you please introduce yourself?
Nikita Popov 0:36: Hi, Derick. I’m Nikita and I am still working at JetBrains. And still working on PHP core development.
Derick Rethans 0:43: Just like about half an hour ago when we recorded an earlier episode.
Nikita Popov 0:47: Exactly.
Derick Rethans 0:48: This RFC has no relation to read only properties. What is the first class callable syntax RFC about?
Nikita Popov 0:55: The context here is that PHP has the callable syntax based on literals, which is that if you just use a plain string, it’s interpreted as a function name, and an array where the first element is an object, and the second one is a method name, that’s methods. Or the first element is the class name, and the second one is method name, that’s a static method.
Derick Rethans 1:17: I would consider this concept a bit of a hack, especially the the one with the arrays, and I reckon you feel similar and hence this RFC?
Nikita Popov 1:27: Yes, I do. So the current callable syntax has a couple of issues. I think the core issue is that it’s not really analysable. So if you see this kind of like array with two strings inside it, it could just be an array with two strings, you don’t know if that’s supposed to actually be a static method reference. If you look at the context of where it is used, you might be able to figure out that actually, this is a callable. And like in your IDE, if you rename this method, then this array should also be this array element will also be renamed. But there’s like a lot of complex reasoning that the static analyser has to perform. That’s one side of the issue. The second one is that callables are not scope independent. For example, if you have a private method, then like at the point where you create your callable, like as an array, it might be callable there, but then you pass it to some other function. And that’s in a different scope. And suddenly that method is not callable there. So this is a general issue with both like this callable syntax based on arrays, and also the callable type. It’s a callable at exactly this point, not callable at a later point. This is what the new syntax essentially addresses. So it provides a syntax that like clearly indicates that yes, this really is a callable, and it performs the callable callability check at the point where it’s created, and also binds the scope at that time. So if you pass it to a different function in a different scope, it still remains callable.
Derick Rethans 3:01: And it’s guaranteed to always be callable.
Nikita Popov 3:03: Yeah, exactly.
Derick Rethans 3:04: What does the syntax like?

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

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

The PHP team is pleased to announce the first beta release of PHP 8.1.0, Beta 1. 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 Beta 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 Beta 2, planned for Aug 5 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.

A series of unfortunate commits: notable software security stories – platform.sh

In March, news broke that two malicious commits were introduced onto the in-development PHP 8.1 branch by perpetrators pretending to be Rasmus Lerdorf and Nikita Popov. The response by the PHP community to this attack was a shining example of the openness and transparency of the open-source world.
We’re going to take a closer look at the PHP 8.1 story to uncover what lessons there are to be learned on the value of visibility in coding.