What changes will be included in PHP8.2 (performance improvements, new features)!

The release time of PHP8.2 has not yet been determined, but it is expected to be released at the end of 2022. This article will introduce you to the features, performance improvements, deprecated features, etc. in the new version.

Related recommendations: The latest progress of PHP8.2, new features will be frozen soon!

null and false will be treated as independent types

PHP will not fall into the direction of perfect type safety , but from a technical point of view, it is worthwhile to treat null and false as independent data types. Under normal circumstances, many common functions in PHP will indicate an error by returning false. For example, in file_get_content:

file_get_contents(/* … */): string|false

In the past, false could be used in union types, but it could not be used independently. In PHP8.2, it can be used alone: ​​

function alwaysFalse(): false
{
    return false;
}

Of course, for this approach, Some developers are wary. It does not support true as an independent type. These developers believe that false is just a value and that types should represent categories rather than values. Of course, in the type system, there is a concept of unit type, which is a type that only allows one value. But does this really work?

But another RFC is also discussing adding true as a type to PHP.

An independent null is very meaningful, so that the empty object pattern can be simply implemented:

class Post
{
    public function getAuthor(): ?string { /* … */ }
}

class NullPost extends Post
{
    public function getAuthor(): null { /* … */ }
}

This can be said for NullPost::getAuthor() that it will only return null, no need to do it like before In that case, null and string must be jointly declared together.

Deprecate dynamic properties

This is a better design for the language specification, but it also restricts many uses. Dynamic properties are deprecated in PHP 8.2 and will throw error exceptions in PHP.

What are dynamic properties? That is, you did not declare these properties in the class, but you can still set and get them:

class Post
{
    public string $title;
}

// …

$post->name = 'Name';  // 在PHP8.2中不能这样使用，因为并没有在类中声明

But don’t worry, magic methods such as __set and __get will still work as expected:

class Post
{
    private array $properties = [];

    public function __set(string $name, mixed $value): void
    {
        $this->properties[$name] = $value;
    }
}

// …

$post->name = 'Name';

Standard objects Same thing: stdClass will continue to support dynamic properties.

PHP used to be a highly dynamic dynamic language, but now many people are willing to accept more rigorous programming methods. Being as strict as possible and relying on static analysis as much as possible is a good thing, because it allows developers to write better code.

However, some developers who value dynamic properties may be very dissatisfied with this change. If you don’t want to see these warnings when using PHP8.2, you can do this:

Yes Using #[AllowDynamicProperties]

#[AllowDynamicProperties]
class Post
{
    public string $title;
}

// …

$post->name = 'Name'; // 一切正常

Another way is to modify the alarm level, but this is not recommended. You will run into trouble when you plan to upgrade to PHP9.0.

error_reporting(E_ALL ^ E_DEPRECATED);

Parameter desensitization when tracing calls

What is parameter desensitization? When we develop, when we encounter errors, we use Trace to debug, but the current stack records some sensitive data, such as environment variables, passwords, and users.

In PHP8.2, some editing of parameters is allowed (Redact, let’s call it editing, has some modification meaning, but it is not appropriate to call it modification directly), such as desensitizing some parameters, so that these The calling value of the parameter will not be listed in the stack information:

function test(
    $foo,
    #[\SensitiveParameter] $bar,
    $baz
) {
    throw new Exception('Error');
}

test('foo', 'bar', 'baz');

If an error is reported, you will find that the second parameter bar does not record the actual value. This can have a desensitizing effect. If the password is passed, it will not be recorded.

Fatal error: Uncaught Exception: Error in test.php:8
Stack trace:
#0 test.php(11): test('foo', Object(SensitiveParameterValue), 'baz')
#1 {main}
  thrown in test.php on line 8

The calling methods of some objects are deprecated

Some previous methods of calling objects are deprecated. Some of these need to be called through call_user_func($callable), rather than being called directly by $callable().

"self::method"
"parent::method"
"static::method"
["self", "method"]
["parent", "method"]
["static", "method"]
["Foo", "Bar::method"]
[new Foo, "Bar::method"]

Why do you do this? Nikita explained it well in the RFC discussion:

These deprecated calls are context-specific, and the method referred to by "self::method" depends on which class the call is executed from or Callability check. In fact, this usually applies to the last two cases as well when used in the form [new Foo, "parent::method"].

Reducing the context dependency of callable objects is a 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 in the future callable objects are limited to public methods, then callable types will become well-defined and can be used as property types. However, changes to visibility handling are not recommended as part of this RFC.

Improve the detection mechanism and level of undefined variables

Undefined variables are those that have not been read before they are read The variable being initialized. Accessing an undefined variable currently emits E_WARNING "Warning: undefined variable $varname" and treats the variable as null, but does not interrupt execution, allowing code execution to continue unabated, but possibly in an unexpected state.

Currently, some configurations can be used to allow PHP to generate error-level exceptions for undefined variables when executing, but this requires separate configuration. PHP should provide safer checks by default.

一般什么情况下会出现未定义变量的情况呢？

用法1

变量在某个分支中声明，比如在if中设置一个值。

if  ( $user -> admin )  {
   $restricted  =  false ;
}

if  ( $restricted )  {
   die ( '你没有进入这里的权限' ) ;
}

用法2

变量拼写错误：

$name = 'Joe';
echo 'Welcome, ' . $naame;

这种用法在1中也可能会发生：

if ($user->admin) {
   $restricted = false;
} else {
   $restrictedd = true;
}

if ($restricted) {
   die('You do not have permission to be here');
}

用法3

在循环中定义，但这个循环可能并没有执行：

while ($item = $itr->next()) {

   $counter++; // 定义变量
}

  // 这里调用了变量，但是很有可能并没有定义这个变量
echo 'You scanned ' . $counter . ' items';

解决方法

在这些分支之前提前定义好一个默认值。

对于第1种用法：

$restricted = true;
if ($user->admin) {
   $restricted = false;
}

if ($restricted) {
   die('You do not have permission to be here');
}

对于第3种用法：

$counter = 0;
while ($item = $itr->next()) {
   $counter++;
}

echo 'You scanned ' . $counter . ' items';

这样做的好处是消除了整个访问和使用这些未定义变量的后果，以及回退到引擎默认状态的用户态错误。这样我们提供了另一层保护，防止PHP程序发生了这种意外后继续运行。

这种更改也会让PHP引擎和JIT等方面不会那么复杂。

这个版本主要是针对PHP9.0的，在PHP8.2的还是警告，在以后会将这种行为提升到错误级别。

增加只读类

通过给类添加只读修饰符来声明只读类。

readonly class Test {
    public string $prop;
}

这样做会隐式地将类的所有实例属性标记为只读。此外，它将阻止创建动态属性。 

readonly class Foo
{
    public int $bar;

    public function __construct() {
        $this->bar = 1;
    }
}

$foo = new Foo();
$foo->bar = 2;
// 抛出错误，不能修改只读属性 Foo::$bar

$foo->baz = 1;
// 抛出错误：不能动态创建属性 Foo::$baz

可以通过增加#[AllowDynamicProperties]属性，可以不触发错误的情况下创建动态属性。

#[AllowDynamicProperties]
readonly class Foo {
}

一些限制：

由于是只读类，必须对属性声明类型：

readonly class Foo
{
    public $bar;
}
// 以上定义会产生错误。

不能使用静态属性：

readonly class Foo
{
    public static int $bar;
}
// 抛出错误: 只读属性不能声明静态类型

原文地址：https://phpreturn.com/index/a626a74a300dc5.html

原文平台：PHP武器库

版权声明：本文由phpreturn.com（PHP武器库官网）原创和首发，所有权利归phpreturn（PHP武器库）所有，本站允许任何形式的转载/引用文章，但必须同时注明出处。

推荐学习：《PHP视频教程》

The above is the detailed content of What changes will be included in PHP8.2 (performance improvements, new features)!. For more information, please follow other related articles on the PHP Chinese website!