12月 10, 2022

PHP 8.2 の新機能

(jp) =

PHP 8.2 は 2022 年 12 月 8 日にリリースされました。 この投稿では、すべての機能、パフォーマンスの向上、変更、および非推奨について 1 つずつ説明します。

# 読み取り専用クラス RFC

読み取り専用プロパティは PHP 8.1 で導入されました。この RFC はそれらの上に構築され、すべてのクラスプロパティを一度に読み取り専用にする構文糖衣を追加します。これを書く代わりに：

class Post

    public function __construct(
        public readonly string $title, 
        public readonly Author $author,
        public readonly string $body,
        public readonly DateTime $publishedAt,
    )

これで次のように記述できます。

readonly class Post

    public function __construct(
        public string $title, 
        public Author $author,
        public string $body,
        public DateTime $publishedAt,
    )

機能的には、クラスを読み取り専用にすることは、すべてのプロパティを読み取り専用にすることとまったく同じです。ただし、動的プロパティがクラスに追加されるのも防ぎます。

$post = new Post();

$post->unknown = 'wrong';

Uncaught Error: Cannot create dynamic property Post::$unknown

子クラスも読み取り専用の場合、読み取り専用クラスからのみ拡張できることに注意してください。

PHP は大幅に変更されており、読み取り専用クラスの追加は歓迎されています。必要に応じて、PHP の進化に関する私のビデオもご覧ください。

# 動的プロパティの廃止 RFC

これは良い方向への変化だと思いますが、少し痛いでしょう。動的プロパティは PHP 8.2 で非推奨になり、 ErrorException PHP 9.0 では:

class Post

    public string $title;




$post->name = 'Name';

実装するクラスに注意してください __get と __set 意図したとおりに動作します:

class Post

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




$post->name = 'Name';

非推奨が役立つ理由とその対処方法について詳しく知りたい場合は、非推奨の対処方法に関する次の投稿を読むか、私の vlog をチェックしてください。

# 新しいランダム拡張 RFC

PHP 8.2 では新しい乱数ジェネレーターが追加され、以前の乱数ジェネレーターの多くの問題が修正されました。 PHP のランダム関数を使用する際に検出が困難なさまざまなバグを排除します。

という新しいクラスがあります。 Randomizer、ランダマイザーエンジンを受け入れます。必要に応じて、そのエンジンを変更できるようになりました。たとえば、本番環境とテスト環境を区別するためです。

$rng = $is_production
    ? new Random\Engine\Secure()
    : new Random\Engine\Mt19937(1234);
 
$randomizer = new Random\Randomizer($rng);
$randomizer->shuffleString('foobar');

# `null`、 `true`、と `false` スタンドアロン型として RFC

PHP 8.2 では、3 つの新しい型 (またはそれに似たもの) が追加されています。この投稿では、タイプセーフのうさぎの穴を掘り下げることは避けますが、技術的には null、 true、と false 単独で有効なタイプと見なすことができます。一般的な例は、PHP の組み込み関数です。 false エラー発生時の戻り値の型として使用されます。たとえば、 file_get_contents:

file_get_contents(): string|false

PHP 8.2より前では、すでに使用できました false ユニオンとして他のタイプと一緒に。ただし、スタンドアロン型としても使用できるようになりました。

function alwaysFalse(): false

    return false;

同じことが今も当てはまります true と null.

# 選言正規形タイプ RFC

DNF 型を使用すると、厳密な規則に従って、結合型と交差型を組み合わせることができます。結合型と交差型を結合する場合、交差型は括弧でグループ化する必要があります。実際には、次のようになります。

function generateSlug((HasTitle&HasId)|null $post) 

    if ($post === null) 
        return '';
    

    return 
        strtolower($post->getTitle()) 
        . $post->getId();

この場合、 (HasTitle&HasId)|null DNFタイプです。

特に、この機能の最も重要な使用例である、null 許容の交差タイプを使用できるようになったことを意味するため、これは素晴らしい追加です。

# 特性の定数 RFC

特性で定数を使用できるようになりました。

trait Foo 

    public const CONSTANT = 1;
 
    public function bar(): int 
    
        return self::CONSTANT;

特性の外部または内部から、特性の名前を介して定数にアクセスすることはできません。

trait Foo 

    public const CONSTANT = 1;
 
    public function bar(): int 
    
        return Foo::CONSTANT;
    


Foo::CONSTANT;

ただし、パブリックである場合は、特性を使用するクラスを介して定数にアクセスできます。

class MyClass

    use Foo;


MyClass::CONSTANT;

# バックトレースのパラメーターを編集する RFC

どのコードベースでも一般的に行われているのは、プロダクションエラーを追跡するサービスに送信し、問題が発生したときに開発者に通知することです。このプラクティスには、多くの場合、ネットワークを介してサードパーティサービスにスタックトレースを送信することが含まれます。ただし、これらのスタックトレースには、環境変数、パスワード、ユーザー名などの機密情報が含まれる場合があります。

PHP 8.2 では、このような「センシティブなパラメーター」を属性でマークできるため、問題が発生したときにスタックトレースにリストされることを心配する必要はありません。 RFC の例を次に示します。

function login(
    string $user,
    #[\SensitiveParameter] string $password
) 
    
    
    throw new Exception('Error');

 
login('root', 'root');
 
Fatal error: Uncaught Exception: Error in login.php:8
Stack trace:


  thrown in login.php on line 8

# const 式で列挙型のプロパティを取得する RFC

RFC から:

このRFCは、の使用を許可することを提案しています ->/?-> 定数式で列挙型のプロパティを取得します。この変更の主な動機は、配列キーなど、列挙オブジェクトが許可されていない場所で名前と値のプロパティを取得できるようにすることです。

これは、次のコードが有効であることを意味します。

enum A: string 

    case B = 'B';
    
    const C = [self::B->value => self::B];

# 戻り値の型の変更 `DateTime::createFromImmutable()` と `DateTimeImmutable::createFromMutable()` 速報

以前は、これらのメソッドは次のように見えました。

DateTime::createFromImmutable(): DateTime
DateTimeImmutable::createFromMutable(): DateTimeImmutable

PHP 8.2 では、これらのメソッドシグネチャは次のように変更されます。

DateTime::createFromImmutable(): static
DateTimeImmutable::createFromMutable(): static

この変更は、から拡張するクラスの静的な洞察の可能性を向上させるため、より理にかなっています。 DateTime と DateTimeImmutable. ただし、技術的には、これはこれら 2 つのクラスのいずれかから拡張されたカスタム実装に影響を与える可能性がある重大な変更です。

# `utf8_encode()` と `utf8_decode()` 非推奨 RFC

PHP 8.2 では、次のいずれかを使用します。 utf8_encode() また utf8_decode() これらの廃止通知をトリガーします。

Deprecated: Function utf8_encode() is deprecated
Deprecated: Function utf8_decode() is deprecated

RFC は、これらの関数の名前が不正確であり、混乱を招くことが多いと主張しています。これらの関数は、 ISO-8859-1 と UTF-8、関数名はより広い用途を示唆しています。 RFC の理由について、より詳細な説明があります。

代替案は？ RFCは使用を提案しています mb_convert_encoding() 代わりは。

# ロケールに依存しない `strtolower()` と `strtoupper()` 速報 RFC

両方 strtolower() と strtoupper() ロケールに依存しなくなりました。使用できます mb_strtolower() ローカライズされた大文字と小文字の変換が必要な場合。

# いくつかの SPL メソッドに対する署名の変更速報

SPL クラスのいくつかのメソッドが変更され、正しい型シグネチャが適切に適用されるようになりました。

SplFileInfo::_bad_state_ex()
SplFileObject::getCsvControl()
SplFileObject::fflush()
SplFileObject::ftell()
SplFileObject::fgetc()
SplFileObject::fpassthru()
SplFileObject::hasChildren()
SplFileObject::getChildren()

＃新しい `n` PCRE の修飾子アップグレード

を使用できるようになりました。 n 修飾子 (NO_AUTO_CAPTURE）の pcre* 機能。

# ODBC ユーザー名とパスワードのエスケープ速報

アップグレードガイドから：

の ODBC 拡張機能は、接続文字列とユーザー名/パスワードの両方が渡され、文字列を追加する必要がある場合に、ユーザー名とパスワードをエスケープするようになりました。

同じことが当てはまります PDO_ODBC.

tpyoに気づきましたか？ PR を送信して修正することができます。このブログの最新情報を知りたい場合は、私をフォローしてください。ツイッターまたは私のニュースレターを購読してください：

# 非推奨 `$` 文字列補間 RFC

PHP には、文字列に変数を埋め込む方法がいくつかあります。この RFC では、めったに使用されず、混乱を招くことが多いため、2 つの方法を非推奨にしています。

"Hello $world";
Deprecated: Using $ in strings is deprecated
 
"Hello $(world)";
Deprecated: Using $ (variable variables) in strings is deprecated

明確にするために: 文字列補間の 2 つの一般的な方法は引き続き機能します。

"Hello $world";
"Hello $world";

# 部分的にサポートされている callable を非推奨にする RFC

もう 1 つの変更は、影響がわずかに小さいものですが、部分的にサポートされている callable も非推奨になったことです。部分的にサポートされている callable は、次を使用して呼び出すことができる callable です。 call_user_func($callable)、しかし呼び出すことによってではありません $callable() 直接。ちなみに、これらの種類の callable のリストはかなり短いです。

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

これを行う理由は？これは、使用できるようになるための正しい方向への一歩です callable 型付きプロパティ用。 Nikita は RFC で非常によく説明しています。

これらの callable はすべてコンテキスト依存です。「self::method」が参照するメソッドは、呼び出しまたは呼び出し可能性チェックが実行されるクラスによって異なります。実際には、これは通常、次の形式で使用される場合、最後の 2 つのケースにも当てはまります。 [new Foo, “parent::method”].

callable のコンテキスト依存性を減らすことは、この RFC の二次的な目標です。この RFC の後、残っている唯一のスコープ依存性はメソッドの可視性です。「Foo::bar」は、あるスコープでは可視であるかもしれませんが、別のスコープでは可視ではないかもしれません。将来、callable がパブリックメソッドに制限される場合 (プライベートメソッドは、スコープに依存しないようにするために、ファーストクラスの callable または Closure::fromCallable() を使用する必要があります)、callable 型は明確に定義され、プロパティタイプとして使用されます。ただし、可視性処理の変更は、この RFC の一部として提案されていません。

現時点ではこれですべてです。このリストは年間を通じて更新されます。時折更新を受け取りたい場合は、私のニュースレターを購読することができます!

次の投稿

犬はマカダミアナッツを食べても大丈夫？

前の投稿

CoD: Modern Warfare 2 と Warzone 2 のミッドシーズンアップデートには、レイドとサッカーをテーマにした LTM が含まれています