Attributes v2というRFCが投票中です。
投票期間は2020/05/04まで、投票者の2/3の賛成で受理されます。
2020/04/27時点では賛成48反対1で、ほぼ間違いなく可決されます。
Attributes v2
Introduction
このRFCは、クラス/プロパティ/関数/メソッド/引数/定数の宣言に、構造化されたアトリビュートをメタデータとして記述できるようにする提案です。
アトリビュートは、コードの宣言に直接設定ディレクティブを埋め込むことで定義されます。
同じような概念としてJavaのAnnotation、C#/C++/Rust/HackにおけるAttribute、Python/JavascriptにおけるDecoratorが存在します。
これまで、PHPではこのようなメタデータとしては非構造的であるdoc-commentsしか存在しませんでした。
しかしdoc-commentsはただの文字列であり、言語によって解釈されることはありません。
構造化された情報を保持するために、PHPの様々なコミュニティにおいて@ベースの疑似メタデータが考案されてきました。
ユーザランドでの使用例に加え、拡張機能などではコンパイルや構文解析、コード生成、実行時の挙動に影響を与えるようなアトリビュートの使用例も多く存在します。
下のほうに例を示します。
ユーザランドのdoc-commentsが多く使われていることから、この機能がコミュニティから強く求められていることがわかります。
Proposal
Attribute Syntax
アトリビュートは、既存の構文トークンT_SLとT_SR、すなわち<<と>>を使った特別なフォーマットのテキストです。
アトリビュートは言語内の多くの対象に適用されます。
・関数 (クロージャやアロー関数含む)
・クラス (無名クラス含む)、インターフェイス、トレイト
・クラス定数
・プロパティ
・メソッド
・関数/メソッド引数
以下は例です。
<<ExampleAttribute>>
class Foo
{
<<ExampleAttribute>>
public const FOO = 'foo';
<<ExampleAttribute>>
public $x;
<<ExampleAttribute>>
public function foo(<<ExampleAttribute>> $bar) { }
}
$object = new <<ExampleAttribute>> class () { };
<<ExampleAttribute>>
function f1() { }
$f2 = <<ExampleAttribute>> function () { };
$f3 = <<ExampleAttribute>> fn () => 1;
アトリビュートはdoc-blockコメントと同様に、それが属する宣言の直前に記載します。
doc-blockコメントとどちらが先かといえば、コメントの前にも後ろにも書くことができます。
<<ExampleAttribute>>
/** docblock */
<<AnotherExampleAttribute>>
function foo() {}
関数、クラス、メソッド、プロパティ、パラメータはひとつ以上のアトリビュートを持つことができます。
<<WithoutArgument>>
<<SingleArgument(0)>>
<<FewArguments('Hello', 'World')>>
function foo() {}
ひとつの対象に同じアトリビュート名を複数回指定することが可能です。
アトリビュートは1行で複数回宣言できます。
<<WithoutArgument>><<SingleArgument(0)>><<FewArguments('Hello', 'World')>>
function foo() {}
<<``>>は式の接頭辞として使用されており、他言語で使用されているジェネリクスの一般的な構文<T>がもし今後導入されることになったとしても、それがアトリビュート構文と衝突することはありません。
構文についてはこのRFCで最も議論されてきたポイントであり、@:として表される新たな構文トークンT_ATTRIBUTEを導入する代替案も考えられました。
構文の選択はRFCの二次投票となります。
@:WithoutArgument
@:SingleArgument(0)
@:FewArguments('Hello', 'World')
function foo() {}
この構文は、doc-blockコメントで一般的に見られる@を使用します。
欠点としては、空白を許可するとアトリビュートの終端を判別できなくなってしまうので、空白を禁止しなければならないことです。
最も要望されるであろう@や[]が使えない理由については、下にあるAlternative Syntaxの議論を参照してください。
Attribute Names Resolve to Classes
アトリビュートは、コンパイル中にその時点でインポートされている全てのシンボルについて解決されます。
これはアトリビュートに名前空間を許容するためであり、別のライブラリやアプリケーションで同じアトリビュートが誤って再利用されるのを避けるためです。
use My\Attributes\SingleArgument;
use My\Attributes\Another;
<<SingleArgument("Hello")>>
<<Another\SingleArgument("World")>>
<<\My\Attributes\FewArguments("foo", "bar")>>
function foo() {}
このことはクラスにアトリビュートを宣言する際にも利点があります。
・リフレクションが解析しやすい。後述。
・静的解析ツールによる検証が容易になる。
・IDEがオートコンプリートや引数に対応することができる。
クラスアトリビュートを指定する例は以下のようになります。
namespace My\Attributes;
use PhpAttribute;
<<PhpAttribute>>
class SingleArgument
{
public $value;
public function __construct(string $value)
{
$this->value = $value;
}
}
Compiler and Userland Attributes
このRFCは、2種類のアトリビュートを区別しています。
・コンパイラアトリビュート：コンパイル時に検証される
・ユーザランドアトリビュート：リフレクションで検証される
コンパイラアトリビュートは、PhpCompilerAttributeに属する内部クラスです。
ユーザランドアトリビュートは、PhpAttributeに属するユーザランドのクラスです。
コンパイル時にコンパイラアトリビュートが見つかると、実行エンジンはアトリビュートに紐付けられているバリデーションのコールバックを呼び出します。
たとえばこのパッチにはPhpCompilerAttributeのバリデーションコールバックが含まれており、ユーザがPhpCompilerAttributeを使うのを防いでいます。
#include "zend_attributes.h"
void zend_attribute_validate_phpcompilerattribute(zval *attribute, int target)
{
if (target != ZEND_ATTRIBUTE_TARGET_CLASS) {
zend_error(E_COMPILE_ERROR, "The PhpCompilerAttribute can only be used on class declarations and only on internal classes");
} else {
zend_error(E_COMPILE_ERROR, "The PhpCompilerAttribute can only be used by internal classes, use PhpAttribute instead");
}
}
INIT_CLASS_ENTRY(ce, "PhpCompilerAttribute", NULL);
zend_ce_php_compiler_attribute = zend_register_internal_class(&ce);
zend_compiler_attribute_register(zend_ce_php_compiler_attribute, zend_attribute_validate_phpcompilerattribute);
引数zvalは渡された全ての引数を含み、targetはアトリビュートが正しく宣言されているかを検証する為の定数です。
ユーザランドクラスはPhpCompilerAttributeを使用することができません。
使おうとするとエラーが発生します。
<?php
<<PhpCompilerAttribute>>
class MyAttribute
{
}
// Fatal error: The PhpCompilerAttribute can only be used by internal classes, use PhpAttribute instead
アトリビュートをクラスツールにマッピングすることで、エディタやIDEは、アトリビュートの構文やコンテキスト情報を開発者に提供することができます。
この方法の欠点は、コンパイラアトリビュートがユーザランドアトリビュートであると誤って分類されてしまうことです。
Constant Expressions in Attribute Arguments
アトリビュートは定数AST式として評価されますが、これは引数を許可することを意味します。
<<SingleArgument(1+1)>>
<<FewArguments(PDO::class, PHP_VERSION_ID)>>
この主な使用例は、定数/クラス定数を参照することです。
定数を参照することで、既に定数として存在する情報を再定義する重複を避けることができます。
もうひとつの利点として、ツールやIDEによる静的解析でアトリビュートを検証できるということです。
定数ASTは、リフレクションを通してアクセスする際は値に解決されます。
これはかつて提出されたアトリビュートRFCとは意図的に異なる挙動です。
またパーサは、ビットシフト演算子とアトリビュート構文を区別できます。
<<BitShiftExample(4 >> 1, 4 << 1)>>
function foo() {}
Reflection
ReflectionクラスにgetAttributes()メソッドが追加され、ReflectionAttributeインスタンスの配列を返します。
function ReflectionFunction::getAttributes(string $name = null, int $flags = 0): ReflectionAttribute[];
function ReflectionClass::getAttributes(string $name = null, int $flags = 0): ReflectionAttribute[];
function ReflectionProperty::getAttributes(string $name = null, int $flags = 0): ReflectionAttribute[];
function ReflectionClassConstant::getAttributes(string $name = null, int $flags = 0): ReflectionAttribute[];
引数$nameがあれば指定したアトリビュート、もしくはそのサブクラスを含めたものを返します。
$attributes = $reflectionFunction->getAttributes(\My\Attributes\SingleArgument::class);
引数$flagが未指定の場合、getAttributes()メソッドは名前が完全一致したアトリビュートだけを返し、この動作がデフォルトです。
ReflectionAttribute::IS_INSTANCEOFを指定すると、instanceofを通過する全てのアトリビュートを返すようになります。
$attributes = $reflectionFunction->getAttributes(
\My\Attributes\MyAbstractAttribute::class,
\ReflectionAttribute::IS_INSTANCEOF
);
ReflectionAttributeクラスは以下のようになります。
class ReflectionAttribute
{
public function getName(): string
public function getArguments(): array
public function newInstance(): object
}
アトリビュートの検証はReflectionAttribute::newInstance()でのみ行われるので、実は必ずしもアトリビュート名に対応したクラスを定義する必要はありません。
アトリビュート名と引数は直接ReflectionAttributeから取って来れます。
以下は完全な例です。
namespace My\Attributes {
<<PhpAttribute>>
class SingleArgument {
public $argumentValue;
public function __construct($argumentValue) {
$this->argumentValue = $argumentValue;
}
}
}
namespace {
<<SingleArgument("Hello World")>>
class Foo {
}
$reflectionClass = new \ReflectionClass(Foo::class);
$attributes = $reflectionClass->getAttributes();
var_dump($attributes[0]->getName());
var_dump($attributes[0]->getArguments());
var_dump($attributes[0]->newInstance());
}
/**
string(28) "My\Attributes\SingleArgument"
array(1) {
[0]=>
string(11) "Hello World"
}
object(My\Attributes\SingleArgument)#1 (1) {
["argumentValue"]=>
string(11) "Hello World"
}
**/
この使い方では、getAttributes()は決して例外をスローしません。
これにより、異なるライブラリが同じ名前のアトリビュートを定義していた際の問題を回避することができます。
Use Cases
Use Cases for PHP Extensions
アトリビュートの主な使用先は、PHPコアと拡張モジュールになるでしょう。
HashTablesへのアトリビュートは、全てのzend_class_entry/op_array/zend_property_info/zend_class_constantで使用可能です。
PHPコアや拡張モジュールは、ある定義にアトリビュートがあるかどうかチェックしたくなることがあるでしょう。
例としてOpcache JITに対する@jitのチェックなどです。
これは、関数やメソッドを常に最適化するようJITに指示します。
アトリビュートが実装されれば、拡張モジュールでは以下のように書けるようになります。
static int zend_needs_manual_jit(const zend_op_array *op_array)
return op_array->attributes &&
zend_hash_str_exists(op_array->attributes, "opcache\\jit", sizeof("opcache\\jit")-1));
開発者は、doc-commentのかわりにアトリビュートを使うことができます。
use Opcache\Jit;
<<Jit>>
function foo() {}
Other potential core and extensions use cases/ideas
以下はアトリビュートの使用法のアイデアです。
RFCの一部ではないことに注意してください。
関数/メソッドの非推奨。
アトリビュートを持つほぼ全ての言語にこの機能が組み込まれています。
PHPにこれがあれば、クラスやプロパティ、定数を非推奨にすることができます。
// アイデアだよ。RFCの一部ではないよ
use Php\Attributes\Deprecated;
<<Deprecated("Use bar() instead")>>
function foo() {}
非推奨アトリビュートは、今のところtrigger_errorを使うことができません。
class Foo
{
<<Deprecated()>>
const BAR = 'BAR';
}
echo Foo::BAR;
// PHP Deprecated: Constant Foo::BAR is deprecated in test.php on line 7
Reclassify Engine WarningsやSupport Rewinding GeneratorsのRFCのようなレガシー動作を、オプトインで変更します。
Rustが似たような機能を持っています。
// アイデアだよ。RFCの一部ではないよ
use Php\Attributes\Deny;
use Php\Attributes\Allow;
<<Allow("rewind_generator")>>
function bar() {
yield 1;
}
<<Deny("undeclared_variables")>>
function foo() {
echo $foo;
// PHP Fatal error: Uncaught TypeError: Access to undeclared variable $foo
}
<<Deny("dynamic_properties")>>
class Foo {
}
$foo->bar; // PHP Fatal error: Uncaught Error: Invalid access to dynamic property Foo::$bar
Rustっぽいマクロの一部は、旧バージョンのPHPでのみPolyfillを読み込んだりするときに便利かもしれません。
ライブラリがOpcacheやpreloadingなどを条件付きで宣言するときに役立つでしょう。
// アイデアだよ。RFCの一部ではないよ
use Php\Attributes\ConditionalDeclare;
use Php\Attributes\IgnoreRedeclaration;
<<ConditionalDeclare(PHP_VERSION_ID < 70000)>> // PHP7.0以上ならASTによって削除される
<<IgnoreRedeclaration>> // 重複時はエラーを出さず単に無視する
function intdiv(int $numerator, int $divisor) {
}
最終的には、あるアトリビュートの引数を返すAPIや、全アトリビュートの一覧を返すAPIが含まれる予定です。
これによって拡張機能の作者は、最小限の労力でアトリビュートを使うことができるようになります。
以下は草案です。
/* アトリビュート名から引数一覧を返す */
HashTable *zend_attribute_get(HashTable *attributes, char *name, size_t name_len);
/* アトリビュートを返す */
zval *zend_attribute_all(HashTable *attributes, char *name, size_t name_len);
Userland Use-Case: Declaring Event Listener Hooks on Objects
ユーザランドにおいて、アトリビュートは宣言に対する追加設定を宣言のすぐ傍に置くことができるという利点があります。
以下はSymfonyのEventSubscribersをアトリビュートを使ってリファクタリングする例です。
EventSubscriberInterfaceは、イベントをどのクラスのどのメソッドで処理するかをgetSubscribedEvents()で宣言する必要があります。
// 現在のコード
class RequestSubscriber implements EventSubscriberInterface
{
public static function getSubscribedEvents(): array
{
return [RequestEvent::class => 'onKernelRequest'];
}
public function onKernelRequest(RequestEvent $event)
{
}
}
// リファクタした
<<PhpAttribute>>
class Listener
{
public $event;
public function __construct(string $event)
{
$this->event = $event;
}
}
class RequestSubscriber
{
<<Listener(RequestEvent::class)>>
public function onKernelRequest(RequestEvent $event)
{
}
}
// アトリビュートを使ったイベントディスパッチャ
class EventDispatcher
{
private $listeners = [];
public function addSubscriber(object $subscriber)
{
$reflection = new ReflectionObject($subscriber);
foreach ($reflection->getMethods() as $method) {
// Listenerアトリビュートを取得
$attributes = $method->getAttributes(Listener::class);
foreach ($attributes as $listenerAttribute) {
/** @var $listener Listener */
$listener = $listenerAttribute->newInstance();
// $listener->eventはcallable
$this->listeners[$listener->event][] = [$subscriber, $method->getName()];
}
}
}
public function dispatch($event, $args...)
{
foreach ($this->listeners[$event] as $listener) {
// 呼び出し
$listener(...$args);
}
}
}
$dispatcher = new EventDispatcher();
$dispatcher->addSubscriber(new RequestSubscriber());
$dispatcher->dispatch(RequestEvent::class, $payload);
Userland Use-Case: Migrating Doctrine Annotations from Docblocks to Attributes
アトリビュートのRFCが考慮した主要なケースのひとつが、広く普及しているDoctrine Annotationsライブラリからの移行可能性です。
PHPコアがアトリビュートをサポートすることで、ユーザがDoctrine Annotationsからアトリビュートへ移行するための基盤を確保することができます。
このためこのRFCは、名前空間を使ったアトリビュートの操作が主な要件となっています。
Doctrineおよび任意のユーザランドライブラリは、親クラスの名前フィルタを利用して、興味のあるアトリビュートだけを抽出することができます。
提案のリフレクションAPIを使用し、独自のロジックを追加することで、より厳格なアトリビュートの使用を強制することができるようになります。
以下に、Doctrineのアノテーションと、このRFCのアトリビュートで同じことを実装した複雑なオブジェクトの例を示します。
<?php
use Doctrine\ORM\Attributes as ORM;
use Symfony\Component\Validator\Constraints as Assert;
<<ORM\Entity>>
/** @ORM\Entity */
class User
{
/** @ORM\Id @ORM\Column(type="integer"*) @ORM\GeneratedValue */
<<ORM\Id>><<ORM\Column("integer")>><<ORM\GeneratedValue>>
private $id;
/**
* @ORM\Column(type="string", unique=true)
* @Assert\Email(message="The email '{{ value }}' is not a valid email.")
*/
<<ORM\Column("string", ORM\Column::UNIQUE)>>
<<Assert\Email(array("message" => "The email '{{ value }}' is not a valid email."))>>
private $email;
/**
* @ORM\Column(type="integer")
* @Assert\Range(
* min = 120,
* max = 180,
* minMessage = "You must be at least {{ limit }}cm tall to enter",
* maxMessage = "You cannot be taller than {{ limit }}cm to enter"
* )
*/
<<Assert\Range(["min" => 120, "max" => 180, "minMessage" => "You must be at least {{ limit }}cm tall to enter"])>>
<<ORM\Column(ORM\Column::T_INTEGER)>>
protected $height;
/**
* @ORM\ManyToMany(targetEntity="Phonenumber")
* @ORM\JoinTable(name="users_phonenumbers",
* joinColumns={@ORM\JoinColumn(name="user_id", referencedColumnName="id")},
* inverseJoinColumns={@ORM\JoinColumn(name="phonenumber_id", referencedColumnName="id", unique=true)}
* )
*/
<<ORM\ManyToMany(Phonenumber::class)>>
<<ORM\JoinTable("users_phonenumbers")>>
<<ORM\JoinColumn("user_id", "id")>>
<<ORM\InverseJoinColumn("phonenumber_id", "id", JoinColumn::UNIQUE)>>
private $phonenumbers;
}
アトリビュートは名前付きパラメータをサポートしていないため、少し制限があります。
これがアトリビュートが関数呼び出しのような構文を利用している理由ですが、もし名前付きパラメータがサポートされれば、自動的にこのRFCもその恩恵を受けることになります。
ユーザランドのアトリビュートへの移行には、Rectorのようなツールが役立ちます。
Criticism and Alternative Approaches
Alternative Syntax: Why not use @ or [] like other languages?
どうして@や[]ではないの？
構文として<<と>>を使用する理由は、コードのこの場所でまだ使用できる数少ない構文のひとつであり、その中でも自然に見えるものだからです。
接頭辞演算子としてまだ使われていない他の記号を使うことも可能ですが、実質的に使えそうなものは'%'くらいです。
他に使える記号というのは|、=、/などです。
@と[]は、エラー抑制演算子と配列短縮構文に競合するため使用することができません。
以下のような構文は、現在既に有効なPHPコードです。
[[@SingleArgument("Hello")]]
この構文が配列宣言かアトリビュートかを決定するためには、無制限に先のトークンを調べなければならなくなる可能性があります。
Why not extending Doc Comments?
Doc Commentsをそのまま拡張するのではだめなの？
アトリビュートはDoc Commentsより優れています。
・名前空間により、同じDoc Commentsを使用している複数のライブラリによる競合を防ぎます。
・アトリビュートの存在チェックはo(1)のハッシュキーチェックであり、strstrやDoc Commentsのパースより高性能です。
・アトリビュートをクラスにマッピングすることで、アトリビュートが正しい構文であることを保証し、Doc Commentsの書き間違いによるバグの発生を減らします。
・アノテーションは非常に多くのツールやコミュニティで一般に使われているので大きな需要があります。しかし初心者がコメントと見誤ると混乱を招くことになるでしょう。また/*と/**の違いもバグの原因になります。
PHPで既存のDoc Commentsを解析して構造化することは可能かもしれませんが、Doc Commentsの方言ごとに追加のパーサを呼び出す必要があります。
Doc Commentsは正しい文法になっていない可能性があるため、文法エラーの取り扱いを決めなければなりません。
最終的に、これはPHP内部に別の言語が存在するということになりそうです。
この方法は、アトリビュートを導入するより遙かに複雑となり、望ましくありません。
Why not always map attributes to simple arrays instead for simplicity?
シンプルに、アトリビュートは常に配列にマッピングするようにすればよくない？
アトリビュートのクラス名解決が何故重要なのか、その利点を前のセクションで解説しました。
アトリビュートが正しいかどうかの検証は、文法が正しいかどうかを検証できないDoc Commentsよりも大きなメリットがあります。
Why not a stricter solution like Doctrine Annotations?
Doctrine Annotationsのようにより厳密なソリューションは導入しないの？
このRFCは、PHPの基本的なアトリビュート機能のみを提案しています。
一般的なソリューションを全て解決するためには様々なユースケースを考慮しなければなりませんが、大抵の場合はDoctrineほど細かなシステムは必要ありません。
Why are nested attributes not allowed?
アトリビュートのネストが許可されないのは何故？
アトリビュートのネストとは、あるアトリビュートを他のアトリビュートの引数として定義するということを意味します。
これは引数でアトリビュートを宣言できるということなので、意図的に禁止されています。
Naming (attributes or annotations)
この機能の"アトリビュート"という名前は、既に使われているアノテーションとの混同を避けるために付けられました。
これによってDoctrine AnnotationsはPHP7ではDoc Commentsで実装され、PHP8ではアトリビュートで実装されている、といったことがおこります。
Backward Incompatible Changes
なし。
Proposed PHP Version(s)
PHP8.0
RFC Impact
To Core
トークン、ASTノード、zend_class_entry、zend_class_constant、zend_op_array、zend_property_infoの全てにアトリビュートを追加する必要があります。
To SAPIs
なし。
To Existing Extensions
なし。
JITは@JITではなくOpcache\Jitを、@nojitのかわりにOpcache\Nojitを使うことになる予定ですが、まだ未定です。
To Opcache
パッチに含まれており、100%の互換ではない可能性があります。
New Constants
なし。
php.ini Defaults
なし。
Open Issues
なし。
Future Scope
・名前付きパラメータとの統合
・下位互換性を壊すことなく、既存関数を新しい動作で拡張させる。
・関数/メソッドが呼ばれたとき、プロパティ/定数にアクセスしたときに非推奨を通知する<<Deprecated>>。
・型付きプロパティとアトリビュートで、JSON/XMLからオブジェクトへの直列化がPHPコアでできるようになる。
・<<«SingleArgument("foo"), MultiArgument("bar", "baz")>> を簡単に書けるような短縮構文。
Voting
2020/04/27時点で、導入には賛成48反対1で、ほぼ導入決定です。
構文は<<>>が40人、@:が10人で、<<>>に決まると思われます。
Patches and Tests
・https://github.com/beberlei/php-src/pull/2 <<>>
・https://github.com/kooldev/php-src/pull/2 @:
References
他言語でのアトリビュート/アノテーション/デコレータ。
・Rust Attributes
・C# Attributes
・Java Annotation
・TypeScript/ECMAScript Decorators
・C++ Attributes
・Go Tags
・Attributes in Hack
かつて却下されたり放棄されたRFC。
・Attributes v1
・Annotations v2
・Reflection Annotations using the Doc-Comment
・Simple Annotations
・Annotations in DocBlock RFC
・Class Metadata RFC
感想
ほぼ全員賛成というのがちょっと信じがたいんだけど。
個人的にはどちらかというと賛成ですが、正直もっと意見が割れてもよさそうな提案ですよね。
ということで、PHP8からはアトリビュートが使えるようになります。
例を見るに、AttributeInterfeceをimplementsしたりとかも不要で、普通にクラスを書いたらいきなりアトリビュート名として使えるんですかねこれ。
ちょっとユーザレベルでの使い方がいまいちよくわかりませんでした。
というか正直、全体的に意味のよくわからないところが多々ありました。
私は普段ソースまで追ってないので、いきなりAST構文木とかzend_class_entryとか言われても知らんがな！ってかんじですよ。
きっと誰かが補足してくれるはず。
あと、それでは具体的にデフォルトでどんなアトリビュートが用意されてるの、ってのもRFCには書かれていません。
複雑なアトリビュートを定義するにはどうすればいいの、というのもRFCではちょっとよくわかりません。
このあたりは今後ドキュメントの追加をおねがいしたいところですね。
まあPHPのマニュアルは親切すぎて困るくらい丁寧なので、そのうち充実してくるとは思いますが。