PHP: version 8.2 for more performance
Technically null and false could be considered valid types on their own. Common examples are PHP's built-in functions, where false is used as the return type on error. Note that using false in a union type was already possible; but in PHP 8.2 it can be used as a standalone type.
According to Brent Roose, many developers, including himself, are a little suspicious looking at the RFC which discusses True and False. "It doesn't support true as a standalone type, and shouldn't types represent categories rather than individual values?" “, he wonders. “It turns out there's a concept called unit type in type systems, which are types that allow only one value. But is it really useful, and does it encourage clean software design? Maybe, maybe not. “, he adds. A standalone null type makes a bit more sense: null can be considered a category in itself, not just a value within a category.
It makes sense that NullPost::getAuthor() can say that it will only ever return null, instead of null or string, which wasn't possible before.
Brent Roose recommends avoiding using false as a standalone type to pass error status "I think there are better solutions to such problems. »
Dynamic properties are deprecated in PHP 8.2, and will throw an ErrorException in PHP 9.0. Recall that dynamic properties are properties that are not present on an object, but are nevertheless defined or obtained. Classes implementing __get and __set will still work as expected.
For Brent Roose, PHP used to be a very dynamic language, but he's been moving away from that mindset for some time now. He thinks it's a good thing to adopt stricter rules and rely on static analysis wherever possible, because it allows developers to write better code.
A common practice in any codebase is to send production errors to a service that keeps track of them and notifies developers when something goes wrong. This practice often involves sending stack traces over wire to a third-party service. There are, however, cases where these stack traces may include sensitive information such as environment variables, passwords, or usernames.
PHP 8.2 allows these "sensitive parameters" to be marked with an attribute, so the user doesn't have to worry about them showing up in the log stacks when something goes wrong. Here is an example from the RFC.
Another change, although having a slightly lower impact, is that partially supported callables are now deprecated as well. Partially supported callables are callables that can be called using call_user_func($callable), but not by calling $callable() directly. The list of these types of callables is quite short, by the way:
"self::method"
"parent::method"
"static::method"
["self", "method"]
["parent", "method"]
["static", "method"]
["Foo", "Bar::method"]
[new Foo, "Bar::method"]
The reason for this choice? For some programmers, this is a step in the right direction towards being able to use callable for typed properties. This is well explained in the RFC.
“All of these callables are context dependent. The method self::method refers to depends on the class from which the callability check or call is made. In practice, this also applies to the last two cases, when used as [new Foo, "parent::method"].
Reducing the contextual dependency of callables is the secondary goal of this RFC. After this RFC, the only remaining scope dependency is method visibility: Foo::bar may be visible in one scope, but not in another. If callables were to be restricted to public methods in the future (while private methods should use first-class callables or Closure::fromCallable() to be made scope independent), then the callable type would become well-defined and could be used as a property type. However, changes to visibility management are not offered as part of this RFC. »
Source: Brent Roose's blog
According to Brent Roose, many developers, including himself, are a little suspicious looking at the RFC which discusses True and False. "It doesn't support true as a standalone type, and shouldn't types represent categories rather than individual values?" “, he wonders. “It turns out there's a concept called unit type in type systems, which are types that allow only one value. But is it really useful, and does it encourage clean software design? Maybe, maybe not. “, he adds. A standalone null type makes a bit more sense: null can be considered a category in itself, not just a value within a category.
It makes sense that NullPost::getAuthor() can say that it will only ever return null, instead of null or string, which wasn't possible before.
Brent Roose recommends avoiding using false as a standalone type to pass error status "I think there are better solutions to such problems. »
Dynamic properties are deprecated in PHP 8.2, and will throw an ErrorException in PHP 9.0. Recall that dynamic properties are properties that are not present on an object, but are nevertheless defined or obtained. Classes implementing __get and __set will still work as expected.
For Brent Roose, PHP used to be a very dynamic language, but he's been moving away from that mindset for some time now. He thinks it's a good thing to adopt stricter rules and rely on static analysis wherever possible, because it allows developers to write better code.
A common practice in any codebase is to send production errors to a service that keeps track of them and notifies developers when something goes wrong. This practice often involves sending stack traces over wire to a third-party service. There are, however, cases where these stack traces may include sensitive information such as environment variables, passwords, or usernames.
PHP 8.2 allows these "sensitive parameters" to be marked with an attribute, so the user doesn't have to worry about them showing up in the log stacks when something goes wrong. Here is an example from the RFC.
Another change, although having a slightly lower impact, is that partially supported callables are now deprecated as well. Partially supported callables are callables that can be called using call_user_func($callable), but not by calling $callable() directly. The list of these types of callables is quite short, by the way:
"self::method"
"parent::method"
"static::method"
["self", "method"]
["parent", "method"]
["static", "method"]
["Foo", "Bar::method"]
[new Foo, "Bar::method"]
The reason for this choice? For some programmers, this is a step in the right direction towards being able to use callable for typed properties. This is well explained in the RFC.
“All of these callables are context dependent. The method self::method refers to depends on the class from which the callability check or call is made. In practice, this also applies to the last two cases, when used as [new Foo, "parent::method"].
Reducing the contextual dependency of callables is the secondary goal of this RFC. After this RFC, the only remaining scope dependency is method visibility: Foo::bar may be visible in one scope, but not in another. If callables were to be restricted to public methods in the future (while private methods should use first-class callables or Closure::fromCallable() to be made scope independent), then the callable type would become well-defined and could be used as a property type. However, changes to visibility management are not offered as part of this RFC. »
Source: Brent Roose's blog
