Let's analyze why generics cannot be used in PHP

This article brings you relevant knowledge about PHP, mainly introducing why generics cannot be used in PHP. Next, we will delve into the situation behind generics and PHP to understand why generics Type is not supported as a first class citizen yet, hope this helps.

Recommended study: "PHP Tutorial"

Why we can’t use generics in PHP

us We'll take a deep dive into what's going on behind generics and PHP. It's very interesting and important to understand why generics are not yet supported as first-class citizens in PHP.

Let's see.

There are no generics in PHP. That’s the conclusion to last year’s Nikita. This is simply not feasible.

To understand why Nikita says this, we need to look at how generics are implemented. Generally speaking, there are three possible approaches; programming languages ​​that support generics mostly use one of these three approaches.

The first one is called monomorphic generics. Let’s go back to the first article of this series, in which I showed this collection example:

class StringCollection extends Collection
{
    public function offsetGet(mixed $key): string 
    { /* … */ }
}
class UserCollection extends Collection
{
    public function offsetGet(mixed $key): User 
    { /* … */ }
}

I explained that we can manually create collection classes for each type of collection we need accomplish. The workload will be huge and there will be a lot of code, but it will work.

Monomorphic generics do exactly that, but automatically behind the scenes. At runtime, PHP will not know about the generic Collection class, but rather about two or more specific implementations:

$users = new Collection<User>();
// Collection_User
$slugs = new Collection<string>();
// Collection_string

Monomorphic generics are a perfectly valid approach. For example, Rust uses them. One advantage of this is that there are a series of performance improvements, because there are no more generic type checks at runtime, so these checks are separated before running the code.

But this immediately brings us to the problem of monomorphic generics in PHP. PHP doesn't have an explicit compilation step like Rust does to split a generic class into several concrete implementations; the bottom line is: monomorphic generics do require quite a bit of memory because you're making multiple copies of the same class, but There are some differences. This may not be a big problem for compiled Rust binaries, but it is a serious problem for PHP code running from a central point (server); potentially handling hundreds or thousands of requests per second .

The next option is to reify generics. This is an implementation where the generic class remains as-is and the type information is dynamically evaluated at runtime. C# and Kotlin implement generics, which are the closest to PHP's current type system, since PHP performs all type checking at runtime. The problem here is that it requires a lot of core code refactoring to make materialized generics work, and you can imagine that as we do more and more type checking at runtime, some performance overhead will creep up.

This brings us to the last option: ignore generics completely at runtime. It's like they're not there; after all, a generic implementation of a collection class, for example, can handle all types of input anyway.

So if we ignore all generic type checking at runtime, there won't be any problem.

Well, not so fast. Ignoring generic types at runtime - it's called type erasure, by the way, and Java and Python do this - caused some problems for PHP.

Give me an example: PHP not only uses types for validation, it also uses type information to dynamically convert values ​​from one type to another - this is what I mentioned in the first article of this series. Type Jugglery:

function add(int $a, int $b): int 
{
    return $a + $b;
}
add('1', '2') // 3;

If PHP ignores the generic type of this "string" collection and we accidentally add an integer to it, it will fail to warn if the generic type is removed Us:

$slugs = new Collection<string>();
$slugs[] = 1; // 1 不会被转换为 &#39;1&#39;

The second and more important problem with type erasure—perhaps you've been yelling at your screen by now—is that types disappear. If generic types are removed at runtime, why do we add them?

This makes sense in Java and Pyton because all type definitions are checked before running the code using the static analyzer. Java, for example, runs a built-in static analyzer when compiling your code; something that PHP doesn't do at all: there's no compilation step, and certainly no built-in static type checker.

On the other hand...all the advantages of type checking, the ones we discussed in previous articles; they don't come from PHP's built-in runtime type checker. We're already running the code when PHP's type checker tells us there's a problem. A type error essentially crashes our program.

Instead, most of the added value of type checking comes from static analyzers that don't require us to run the code. As long as programmers provide sufficient type information, they have a good chance of ensuring that runtime type errors will not occur. This does not mean that you cannot have any errors in your code, but it is possible to write PHP code that is fully statically checked and does not produce any type of errors at runtime. The bottom line: we gain all static insights while writing code; this is the most valuable part of any type system, independent of runtime type checking.

So do we really need runtime type checking? Because this is the main reason why you can't currently add generics to PHP: validating generic types at runtime is too complex or too resource-intensive for PHP.

Original address: https://stitcher.io/blog/generics-in-php-3

Translation address: https://learnku.com/php/t/ 66486

Recommended study: "PHP Video Tutorial"

The above is the detailed content of Let's analyze why generics cannot be used in PHP. For more information, please follow other related articles on the PHP Chinese website!