Paul M. Jones

After several rounds of private review, the Response-Interop standard interface package is now open for public review.

Response-Interop provides interoperable interfaces to encapsulate, buffer, and send server-side response values in PHP 8.4 or later, in order to reduce the global mutable state and inspection problems that exist with the PHP response-sending functions. It reflects, refines, and reconciles the common practices identified within several pre-existing projects to define these interfaces:

• ResponseStruct encapsulates the server response status line, headers, and body.

• ResponseHeadersCollection encapsulates the headers for the response, including affordances for cookie management.

• ResponseBodyHandler affords management of non-string, resource-intensive, or header-modifying content.

• ResponseCookieHelperService affords conversion of cookie representations to and from strings and arrays.

• ResponseSenderService affords sending the server response.

• ResponseThrowable extends Throwable to mark an Exception as response-related.

• ResponseTypeAliases provides PHPStan type aliases to aid static analysis.

The reference implementations demonstrate how the interfaces can be used.

If you have to deal with server-side responses and are interested an interoperable set of interfaces, please offer your comments and criticism as issues or PRs out at Github.

In this PHP internals message we read:

I have participated in some internals discussions that point out a fact from the other direction: PHP makes no imposition about file structure. 1-class-per-file is strictly a PSR-4 implementation of a custom autoloader which we have gotten used to for so long. I would really love to be able to declare small related classes/interfaces in a single file ...

There is something to be said for more-than-one class per file, and after a few evenings of tinkering, I can now present the moto/autoload package.

The Moto name-to-file resolution algorithm is an ideological descendant from Horde/PEAR through PSR-0 and PSR-4, with the latest evolution being that everything after an underscore in the terminating class name portion is ignored:

/**
 * Foo_Bar\Baz\ maps to /classes/foo-bar/baz/src/
 */
Foo_Bar\Baz\Dib     => /classes/foo-bar/baz/src/Dib.php
Foo_Bar\Baz\Dib_Zim => /classes/foo-bar/baz/src/Dib.php
Foo_Bar\Baz\Dib_Gir => /classes/foo-bar/baz/src/Dib.php
Foo_Bar\Baz\Dib_Irk => /classes/foo-bar/baz/src/Dib.php

This means the Dib.php file can contain any number of underscore-suffixed classes so long as they are prefixed with Dib ...

// /classes/foo-bar/src/Baz/Dib.php
namespace Foo_Bar/Baz;

class Dib { }

class Dib_Zim { }

class Dib_Gir { }

class Dib_Irk { }

... and a Moto-compliant resolver will find the correct file for that class.

And if function autoloading becomes supported by PHP, the Moto name-to-file resolution algorithm can support multiple functions per file:

// Foo_Bar\Baz => /vendor/foo-bar/baz/src/dib.php
namespace Foo_Bar\Baz;

function dib() {}

function dib_zim() {}

function dib_gir() {}

function dib_irk() {}

I'm soliciting feedback on this approach, so please post your comments and concerns at Github as issues and pull requests.

After an extensive period of untagged private review, the Request-Interop standard interface package is now open for public review.

Request-Interop provides an interoperable package of standard interfaces for encapsulating readable server-side request values in PHP 8.4 or later, in order to reduce the global mutable state problems that exist with PHP superglobals. It reflects, refines, and reconciles the common practices identified within several pre-existing projects to define these interfaces:

• RequestStruct to represent the incoming request.
• RequestStructFactory to create RequestStruct instances.

Request-Interop also defines a marker interface, RequestThrowable, for marking an Exception as request-related.

Finally, Request-Interop defines a RequestTypeAliases interface with PHPStan types to aid static analysis.

The reference implementations demonstrate how the interfaces can be used.

If you have to deal with server-side requests and are interested an interoperable set of interfaces, please offer your comments and criticism as issues or PRs out at Github.

After a brief period of private review, the Upload-Interop standard interface package is now open for public review.

Upload-Interop provides an interoperable package of standard interfaces for working with upload structures in PHP 8.4+. It reflects, refines, and reconciles the common practices identified within several pre-existing projects to define these interfaces:

• UploadStruct represents an individual upload.
• UploadStructFactory affords creating one or more UploadStruct instances.
• UploadThrowable marks an Exception as upload-related.

Upload-Interop also defines an UploadTypeAliases interface with PHPStan types to aid static analysis.

The reference implementations demonstrate how the interfaces can be used.

If you have to deal with uploads and are interested an interoperable set of interfaces, please offer your comments and criticism as issues or PRs out at Github.

I am pleased to announce that the Uri-Interop standard interface package has been released at 1.0.0 stable, along with reference implementations for the interfaces.

The standard includes interfaces for readable, mutable, and immutable URI objects, as well as URI-specific PHPStan type aliases.

The standard also includes interfaces for a factory. normalizer, resolver, and parser.

If you discover omissions or oversights, please raise an issue or PR at Github.

I am pleased to announce that the Stream-Interop standard interface package has been released at 1.0.0 stable, along with reference implementations for the interfaces.

The standard now includes interfaces for readonly and immutable streams, as well as stream-specific PHPStan type aliases.

If you discover omissions or oversights, please raise an issue or PR at Github.

After a period of private review, the uri-interop/interface package is now open for public review.

Uri-Interop publishes a standard set of interoperable URI interfaces for PHP 8.4+. It reflects, refines, and reconciles the common practices identified within several pre-existing projects.

The package defines separate interfaces to afford reading and modifying URI component values:

• Uri StringableComponents affords reading of the URI component values and recomposing them into a string.
• MutableUri MutableComponents extends Uri StringableComponents to afford direct modification of component values.
• ImmutableUri ImmutableComponents extends Uri StringableComponents to afford immutable modification of component values.

Uri-Interop defines factory and parser interfaces:

• UriFactory UriEncodedFactory affords creating a new URI instance from URI component values.
• UriParser UriEncodedParser affords creating a new URI instance from a URI string.

Uri-Interop defines these marker interfaces to codify expectations around RFC compliance:

• Rfc3986Compliant UriEncoded marks any of the other interfaces to indicate RFC 3986 compliance.
• Rfc3987Compliant IriEncoded marks any of the other interfaces to indicate RFC 3987 compliance.

Finally, Uri-Interop defines an interface of PHPStan type aliases, UriTypeAliases, to aid static analysis.

If you use URI objects (who doesn't!) and are interested an interoperable set of interfaces, please offer your comments and criticism as issues or pull requests out at Github.

UPDATE (Mon 17 Mar 2025): Based on review, some of the interface names have changed since the initial announcement, though their purpose remains the same.

Many thanks to the private reviewers and collaborators on this project thus far. Special thanks to Nathan Bishop for starting this project, and for his generous donation of the Github organization and the Packagist vendor space. Special thanks also to Akihito Koriyama for his encouragement and advice on this and related *-interop projects.

After a period of private review, the stream-interop/interface package is now open for public review.

Stream-Interop publishes interoperable interfaces providing a more object-oriented approach to encapsulating and interacting with stream resources in PHP 8.4+. It reflects, refines, and reconciles the common practices identified within several pre-existing projects.

The package defines separate interfaces for various affordances around stream resources so that (1) implementations can advertise well-tailored affordances, and (2) consumers can typehint to the specific affordances they require for specific situations:

• Stream is a common baseline for streams.
• ResourceStream affords direct access to the encapsulated resource.
• ClosableStream affords closing the stream.
• SizableStream affords getting the full length of the stream in bytes.
• ReadableStream affords reading from the stream.
• SeekableStream affords moving the stream pointer.
• StringableStream affords casting the stream to a string.
• WritableStream affords writing to the stream.

The reference implementations demonstrate how the interfaces can be combined in various ways to implement everything from a simple ConsumableFileStream to a lazy ghost ReadWriteFile.

If you use streams and are interested an interoperable set of interfaces, please offer your comments and criticism as issues or PRs out at Github.

The front-interop project defines a set of interoperable interfaces for the FrontController pattern in PHP to encapsulate the request-receiving and response-sending behaviors at the outermost boundary of your HTTP presentation layer:

• RequestHandler::handleRequest() : ResponseHandler encapsulates the logic to transform an incoming HTTP request to an outgoing HTTP response.

• ResponseHandler::handleResponse() : void encapsulates the logic to send or emit an outgoing response.

These interfaces are completely independent of any particular request/response library. That is, they will work with PSR-7, Symfony HttpFoundation, Sapien, or any other request/response library.

Read more about the project here.

PHP-Styler is a companion to PHP-Parser for reconstructing PHP code after it has been deconstructed into an abstract syntax tree.

I've done quite a bit with PHP-Styler since the last-announced 0.5.0 release a few weeks ago; the most important things are:

1. Comment handling has been greatly improved, including greater fidelity regarding inline comments.
2. There are now instructions on how to customize the Styler presentation.
3. The demo site looks a lot nicer, and has a pretty good logo now.

Even though PHP-Styler is still in its 0.x release series, and is good enough for me to use on my own projects, it would benefit from wider usage to find edge cases. If you try out the Styler and find problems with it, please enter an issue!

Further, if you build a customized style, please let me know, and I can advertise it on the site.