PHP Trait 为何可能成为语言的关键特性

PHP Trait 为何可能成为语言的关键特性

PHP 社区对 Trait 一向谈不上偏爱。它们常被视为隐式行为的来源。既然如此，Trait 为何依然值得重视？

Trait 大概是 PHP 中唯一可以被归入元编程工具集的特性。它允许在程序真正开始使用某个类之前改变该类的结构，实际上就是把方法、属性和常量注入目标类。

当然，Lisp 这类语言，以及 Elixir 这类更现代的语言，都提供了远比 PHP 强大的元编程设施。

但 PHP 的 Trait 具备一个许多同类机制所缺乏的特性：极低的认知负担。

它的模型非常简单：

trait Timestamped
{
    public DateTimeImmutable $createdAt;

    public function touch(): void
    {
        $this->createdAt = new DateTimeImmutable();
    }
}

class User
{
    use Timestamped;
}

完成组合之后，在阅读 User 类时，几乎可以把它当作是这样写成的：

class User
{
    public DateTimeImmutable $createdAt;

    public function touch(): void
    {
        $this->createdAt = new DateTimeImmutable();
    }
}

除少数冲突解决规则之外，类与 Trait 的组合就只是类中定义的一切与 Trait 中定义的一切的简单叠加。

这一规则易于记忆，也相对容易推理。

元编程之所以从未成为大多数程序员的日常工具，原因之一在于：很难理解一个元程序究竟如何改造程序本身。

Trait 在这方面的问题要小得多。它的变换受到约束、范围局限，而且相对直观。

这正是 Trait 的价值所在。

Trait 所缺失的能力

那么，Trait 为何没能在 PHP 中成为更强大的工具？

一个重要原因在于，Trait 与其目标类之间缺乏足够强的组合契约。

目前，Trait 可以通过抽象方法部分地表达自身的要求：

trait Serializable
{
    abstract protected function data(): array;

    public function serialize(): string
    {
        return json_encode($this->data(), JSON_THROW_ON_ERROR);
    }
}

这已经建立了一种契约：目标类必须以某种方式提供 data()。

但是，当 Trait 依赖的契约规模更大时，这种机制很快就会变得笨重。如果 Trait 期望目标类实现整个接口，它就必须逐一重复接口中的方法：

trait IteratorConsumer
{
    abstract public function current(): mixed;
    abstract public function next(): void;
    abstract public function key(): mixed;
    abstract public function valid(): bool;
    abstract public function rewind(): void;

    // ...
}

更自然的写法大致如下：

trait IteratorConsumer require Iterator
{
    // Inside the trait we now know:
    // $this instanceof Iterator
}

而且这并非纯属假想的语法。

PHP 早期的一份 RFC《Horizontal Reuse for PHP》就提出了基本相同的设想：Trait 可以要求其目标类满足某个特定接口。

另一份 RFC《Traits with Interfaces》则提出了这一契约的另一面：

interface Logger
{
    public function error(string $message): void;
    public function info(string $message): void;
}

trait FileLogger implements Logger
{
    public function error(string $message): void
    {
        // ...
    }

    public function info(string $message): void
    {
        // ...
    }
}

这样一来，Trait 就可以作出保证：

只要将它组合进某个类，它便为该接口提供实现。

这份 RFC 走得更远：使用此类 Trait 的类将自动成为该接口的实现。

由此便得到组合契约两个对称的侧面。

trait T require A 意味着：它只能被组合进已经满足 A 的目标。

而 trait T implements B 则意味着：通过组合它，目标类获得了 B。

几乎可以把 Trait 描述为一种类型变换 T : A → A & B。Trait 接受一个满足某种契约的类，并产出一个满足扩展契约的类。

不过还可以再往前推进一步。

契约应当是双向的

Trait 应当能够声明：一个类在被它组合之前必须满足哪些要求。

与此同时，类也应当能够定义自己愿意接受哪些变换。

目前：

class User
{
    use SomeTrait;
}

这实际上等于无条件允许 SomeTrait 把它的成员引入 User。

在双向契约之下，组合本身会成为一种经过检查的操作：

Trait requirements
        ↓
      Class
        ↓
Class permissions
        ↓
    composition

此时，Trait 便不再仅仅是水平代码复用的机制，而成为一种受到约束、可以预期的编译期类变换机制。

这恰恰是 Trait 潜力远未被充分释放的地方。

它能够为 PHP 带来元编程的部分表达能力，同时又不必引入通用宏系统那样的整体复杂度。

PHP Trait 为何可能成为语言的关键特性