PHP RFC: Class and interface name types

• Version: 0.1
• Date: 2017-04-28
• Author: Andrea Faulds, ajf@ajf.me
• Status: Draft
• First Published at: http://wiki.php.net/rfc/class_and_interface_name_types

There are various cases where the fully-qualified name of a class or interface may be returned from or passed as an argument to a function. While PHP has a type declaration for function names, callable, it does not yet have such a type declaration for class or interface names.

This RFC proposes the introduction of three new type declarations for use on parameters and return values:

• classlike, which accepts the name of a class or interface
• class, which accepts the name of a class
• interface, which accepts the name of an interface

These type declarations validate values using the following steps:

1. If the value is not a string, reject it.
2. If there is no currently-loaded class, interface, or trait with the name given by the value, attempt to autoload it.
3. If there is now no currently-loaded class or interface (as appropriate) with the name given by the value, reject the value.
4. Otherwise, accept the value.

A simple example of usage:

<?php
 
function accepts_class(class $class) {
    var_dump($class);
}
 
accepts_class(stdClass::class);    // works
accepts_class("stdClass");         // also works
accepts_class(ArrayAccess::class); // Fatal error: Uncaught TypeError: Argument 1 passed to accepts_class() must be of the type class, string given…

: Talk about Hack, and what it does differently?

: Justify “classlike”/class/interface distinction?

The classlike keyword is now restricted from use as a class, interface or trait name, to avoid conflicting with the type declaration. Breaking backwards-compatibility here is unfortunately necessary in order to introduce a new type declaration. It is the author's opinion that this is unlikely to be a common name in existing code, and therefore should cause few if any backwards-compatibility issues in practice.

This is proposed for the next PHP 7.x, currently PHP 7.2.

Testing revealed that Opcache's type inference needed updating to accommodate the new type declaration. This has been done and it seems to work, but it is possible other areas of incompatibility exist and have been missed.

Classes, interfaces and traits continue not to be objects in themselves, and are only referenced by name.

A supertype of the classlike, class and interface declarations could be introduced, which could name not only classes and interfaces, but also primitive PHP types (int, string etc.) and possibly pseudo-types.

The potential future ability to use variables containing type names in place of literal type names in source code could facilitate generic programming.

This would require a 2/3 majority, as a language change. The vote would be a Yes/No vote as to whether to accept the RFC for the appropriate future version of PHP.

There is a patch here which contains tests: https://github.com/php/php-src/compare/master...hikari-no-yume:class_type_declaration

It does not yet handle inheritance concerns.

There is not yet a pull request.

There is not yet a patch for the language specification.

After the project is implemented, this section should contain

1. the version(s) it was merged to
2. a link to the git commit(s)
3. a link to the PHP manual entry for the feature
4. a link to the language specification section (if any)

: Links to external references, discussions or RFCs