Reusing Behavior with Traits

User and Product have nothing in common — different lifecycles, different storage — yet both need slug generation and both need soft-delete bookkeeping. They cannot share a parent (each already has one, and the relationship would be a lie), and duplicating the methods guarantees drift. A trait is the third axis of reuse: methods that travel sideways across any class:

trait Sluggable
{
    public function slug(): string
    {
        return strtolower(trim(preg_replace('/[^a-z0-9]+/i', '-', $this->title()), '-'));
    }

    abstract public function title(): string;
}

final class User
{
    use Sluggable;

    public function __construct(private string $name) {}
    public function title(): string { return $this->name; }
}

final class Product
{
    use Sluggable;

    public function __construct(private string $label) {}
    public function title(): string { return $this->label; }
}

(new Product('Blue Socks!'))->slug();   // 'blue-socks'

The mechanism deserves a precise mental model: trait methods are flattened into the class at compile time — copied, in effect, into the class's method table — not inherited through any hierarchy and not wrapped in a delegating object. There is no Sluggable instance anywhere; use Sluggable inside a class body is not the same construct as implements SomeInterface nor a second parent. The consequences fall out of that flattening:

• The class's methods always beat trait methods (a same-named class method silently wins — no warning).
• Trait methods see $this and get full access to the class's public and protected members — that is why slug() can call $this->title() even though title() is declared in the class, and why the abstract requirement above is legal.
• Static methods and properties can live in a trait too, one copy per using class.

Traits solve exactly what single inheritance blocks: Inheritance and the extends Keyword gave User and Product one parent slot each, and interfaces like the ones in Contracts with Interfaces carry no bodies to share. A trait carries bodies. The standard-library proof of the concept is IteratorAggregate-style utilities and framework staples like Laravel's HasUuids or Symfony's LoggerAwareTrait — dozens of unrelated classes with one shared implementation each.

The discipline: a trait is a bag of methods, so it should model one coherent capability (Sluggable, Timestamps, SerializesModels), not a grab-bag of leftovers. And because the class always wins conflicts silently, an accidental name collision can shadow a trait's behavior without any diagnostic — which is why the next chapter's conflict tooling matters the moment two traits enter one class.

Traits are also first-class citizens of the runtime: class_uses($obj) returns the trait names an object's class pulled in, and trait_exists('Sluggable') behaves like class_exists for autoloading — a trait lives in its own PSR-4 file, exactly like a class. That file-level visibility is the underrated practical win: one Sluggable.php edited once fixes every slug in the application, and IDE navigation lands on the single definition instead of N duplicated copies. The cost of that win is the invisibility noted above — new User alone gives no hint that half its methods came from files elsewhere — so the convention in healthy codebases is to keep the use list at the top of the class body, name every trait after one loud capability, and treat adding a trait to a shipped class with the same ceremony as adding a public method: it is a visible, reviewable change to what the class can do.

Two traits, one method name, one class:

trait Auditable   { public function stamp(): string { return 'audited at ' . time(); } }
trait Versionable { public function stamp(): string { return 'v' . rand(1, 5); } }

final class Document
{
    use Auditable, Versionable;
}

// Fatal error: Document and Versionable define the same method ("stamp")
// and must use insteadof or as to resolve the conflict

Unlike the class-vs-trait case, trait-vs-trait is a fatal error, not a silent win — the engine refuses to guess. Two keywords resolve it, with deliberately different jobs:

final class Document
{
    use Auditable, Versionable {
        Auditable::stamp insteadof Versionable;   // 1) which implementation wins
        Versionable::stamp as versionStamp;       // 2) keep the loser under a new name
    }
}

$d = new Document();
$d->stamp();         // the Auditable implementation
$d->versionStamp();  // the Versionable one, renamed — nothing was deleted

insteadof picks the survivor for the colliding name; the displaced trait method vanishes from that name's slot unless you re-import it with as. The second job of as is aliasing any trait method — including non-colliding ones — and it can also change visibility on import:

trait SecretHash
{
    protected function hash(string $data): string { return sha1($data); }
}

final class TokenService
{
    use SecretHash { hash as public hashToken; }   // widen: outsiders may now call it
}

Note that as creates an additional name by default — hash remains protected and hashToken becomes the public alias. To change the visibility of the original name itself, you rebind it explicitly (hash as protected; is the no-op form; hash as private; narrows it for this class only). Both operations happen at compile time and neither modifies the trait: every other class using Auditable still gets the untouched stamp(). That non-destructiveness is the design intent — conflict resolution is a per-using-class decision, one line in one class body.

A structural habit keeps most conflicts from arising at all: namespace the capability, not the verb. Auditable::stamp and Versionable::stamp collide because both grabbed the generic name; renaming to auditStamp() and versionStamp() inside the traits themselves eliminates the insteadof entirely. Reach for insteadof when the names must match (you are retrofitting existing code), and for as when you genuinely want two views of one behavior. Collisions are the loud problems; the quiet ones — traits that carry state, or that require capabilities the class forgot to provide — are next.

One more as form deserves recognition because it appears throughout framework code: visibility-only rebinding. use Auditable { stamp as private; } keeps the original name but changes its visibility in this class alone, with no alias involved. The most common real-world driver for the whole toolkit is retrofitting: a vendor trait ships save() that collides with your domain method, or an interface you just implemented demands slugify() while the trait spells it slug(). A two-line resolution block reconciles the shared implementation with your contract instead of forking the vendor's file — which is the entire argument for composition over copy-paste. Debugging tip to carry out of this chapter: when a trait method seems to misbehave, apply the class-wins rule first — grep for a same-named method in the using class and in its parents before blaming the trait itself. Most "broken trait" mysteries resolve into an unnoticed override three levels up the hierarchy.

A trait may declare properties, with a constraint that shapes every design decision about them:

trait HasLimit
{
    private int $limit = 20;          // default required — no promoted properties here

    public function limit(): int { return $this->limit; }

    public function limitTo(int $limit): static
    {
        $this->limit = $limit;
        return $this;
    }
}

final class Query
{
    use HasLimit;
}

final class Report
{
    use HasLimit;

    private int $limit = 50;          // Fatal error: HasLimit and Report define the same property
}

The rule: a class using a trait must not redeclare the trait's property with an incompatible default — same-name properties must be identical in visibility and default, or PHP fatals. And because traits cannot use constructor promotion, every trait property needs a plain declaration with a default; the trait also cannot enforce initialization through a constructor it does not have. State in a trait is therefore fine for configuration with a sane default (a limit, a cache prefix) and poor for anything that must be initialized per instance. The alternative when state coordination matters: keep the property in the class and let the trait operate on it — the same split Sluggable used with title().

Traits may also declare abstract methods, which turns the use statement into a two-way contract — the trait promises behavior and demands capabilities:

trait Exports
{
    abstract public function records(): iterable;

    public function toJson(): string
    {
        return json_encode(iterator_to_array($this->records()), JSON_THROW_ON_ERROR);
    }
}

Any class using Exports must implement records() or be declared abstract — enforced at compile time, exactly like an abstract parent's requirements, which makes traits a surprisingly good home for template-method fragments.

Where traits stop helping is worth stating plainly. They compose methods, not meaning: a class using six traits can become unreadable, its method table assembled from distant files with no single place that answers "what does this object do?" — the failure mode reviewers call trait soup. Traits share no enforced contract (unlike interfaces), so use Sluggable guarantees nothing to a caller unless an interface states the promise too; the healthy pattern pairs them — interface SluggableApi { public function slug(): string; } with the trait supplying the body. And nothing about a trait is inherited: child classes get trait methods only by inheriting the class that used the trait, which is usually what you want but surprises people who expect the trait to re-apply. Used as one-capability-per-trait, backed by an interface, traits fill the exact gap between inheritance's single spine and interfaces' zero bodies.

A last mechanical detail that trips up readers of framework source: use at the top of a PHP file imports a namespace, while use inside a class body composes a trait — same keyword, two unrelated jobs, distinguished purely by position. And when a class both extends a parent and uses traits, the precedence order is fixed and worth memorizing: the class's own methods win first, then trait methods, then inherited parent methods. A trait method therefore overrides an inherited parent method of the same name with no parent:: ceremony, which is exactly why traits retrofit behavior onto existing hierarchies without touching the parent. With methods, contracts, and horizontal reuse all covered, the remaining modern type is for data rather than behavior: Backed Enums for Fixed Values.