PHP 8.4 features: a complete guide to modern PHP development

Created: 06 January 2026 Estimated reading time: 9 minutes

TLDR: PHP 8.4 at a glance

Property hooks enable custom getters/setters without bloated classes—reducing boilerplate while keeping your code clean and type-safe
Asymmetric visibility separates read and write access on properties, giving you fine-grained control over object access patterns
JIT compilation Enhancements push performance further with better optimization strategies for real-world application workloads
Deprecations and breaking changes require attention: implode() parameter order, preg_* return types, and error handling shifts prepare you for PHP 9.0

Introduction: why PHP 8.4 matters

The release of PHP 8.4 represents a significant leap forward in language maturity. While not as flashy as the jump from PHP 7.x to 8.0, this version addresses real pain points that developers encounter daily: verbose getter/setter patterns, inflexible property visibility, and performance bottlenecks in compute-heavy operations.

If you've been building modern PHP applications with Laravel, Symfony, or custom frameworks, you've probably written hundreds of getter and setter methods. PHP 8.4 changes that conversation fundamentally.

In this guide, we'll explore the features that matter to production applications, show you how to implement them safely, and discuss the migration path from earlier versions.

1. Property hooks: say goodbye to Boilerplate

What are property hooks?

Property hooks are computed properties that let you define custom logic for reading and writing to class properties without implementing full getter/setter methods. They're built directly into the property syntax, keeping your code declarative and DRY.

Basic syntax

class User
{
    public function __construct(
        private string $firstName,
        private string $lastName,
    ) {}

    // Property hook with getter and setter
    public string $fullName {
        get => $this->firstName . ' ' . $this->lastName;
        set => function (string $value) {
            [$this->firstName, $this->lastName] = explode(' ', $value, 2);
        };
    }
}

$user = new User('John', 'Doe');
echo $user->fullName; // Output: John Doe

$user->fullName = 'Jane Smith';
echo $user->firstName; // Output: Jane

Real-world example: price calculation with tax

class Product
{
    public function __construct(
        private float $basePrice,
        private float $taxRate = 0.20,
    ) {}

    // Computed property: final price always reflects current tax
    public float $finalPrice {
        get => $this->basePrice * (1 + $this->taxRate);
        set => $this->basePrice = $value / (1 + $this->taxRate);
    }

    public function applyDiscount(float $percent): void
    {
        $this->basePrice *= (1 - $percent / 100);
    }
}

$product = new Product(100);
echo $product->finalPrice; // 120 (with 20% tax)

$product->finalPrice = 150;
echo $product->basePrice; // ~125 (backed out tax)

Common pitfalls & best practices

Pitfall 1: over-engineering simple properties

// Don't do this
class Config
{
    public string $environment {
        get => $this->env ?? 'production';
        set => $this->env = $value;
    }
}

// Do this instead
class Config
{
    public function __construct(
        public string $environment = 'production'
    ) {}
}

Pitfall 2: side effects in hooks

// ⚠️ Avoid state mutation in hooks
class Account
{
    private int $balance = 0;

    public int $balance {
        // ❌ Don't silently log or notify
        set => $this->balance = $value; // ✅ Just assign
    }
}

Best practice: combine hooks with validation

class Email
{
    private string $address;

    public string $email {
        get => $this->address;
        set {
            if (!filter_var($value, FILTER_VALIDATE_EMAIL)) {
                throw new InvalidArgumentException("Invalid email");
            }
            $this->address = $value;
        };
    }
}

When to use Property Hooks

✓ Computed properties that derive from other fields
✓ Lazy-loaded relationships
✓ Properties requiring validation on write
✓ Read-only derived properties with fallback logic

✗ Complex business logic (use methods instead)
✗ Database queries (use explicit methods)
✗ Side effects or logging

2. Asymmetric visibility: fine-grained access control

The problem it solves

Before PHP 8.4, properties were either public (anyone can read and write) or private (nobody from outside). Asymmetric visibility lets you separate read and write access, a pattern popularized by languages like Kotlin and Python.

Syntax & examples

class BankAccount
{
    public function __construct(
        private float $balance = 0.0,
    ) {}

    // Public read, private write
    public private(set) float $balance {
        get => $this->balance;
    }

    public function deposit(float $amount): void
    {
        if ($amount <= 0) {
            throw new InvalidArgumentException("Amount must be positive");
        }
        $this->balance += $amount;
    }

    public function withdraw(float $amount): void
    {
        if ($amount > $this->balance) {
            throw new LogicException("Insufficient funds");
        }
        $this->balance -= $amount;
    }
}

$account = new BankAccount(1000);
echo $account->balance; // ✅ Works: 1000

$account->balance = 9999; // ❌ Error: Cannot modify private property

Real-World Example: Published Content

class BlogPost
{
    public private(set) DateTimeImmutable $publishedAt;
    public private(set) string $status = 'draft';

    public function __construct(
        public readonly string $title,
        public readonly string $content,
        private readonly User $author,
    ) {
        $this->publishedAt = new DateTimeImmutable();
    }

    public function publish(): void
    {
        $this->status = 'published';
        $this->publishedAt = new DateTimeImmutable();
    }

    public function unpublish(): void
    {
        $this->status = 'draft';
    }
}

$post = new BlogPost('PHP 8.4', '...content...', $user);

echo $post->status; // ✅ Can read: 'draft'
$post->status = 'published'; // ❌ Error: Cannot modify private property

$post->publish(); // ✅ Controlled state change

Visibility Combinations

class Order
{
    // Private get, public set (unusual but valid)
    public protected(get) string $internalNotes;

    // Protected read, private write
    public protected private(set) string $customerNotes;

    // Package-private read, private write
    #[Internal]
    public package private(set) array $metadata;
}

Performance & implementation notes

Asymmetric visibility has zero runtime overhead—it's enforced at compile time by PHP's type system. The property still maps to a single internal value. Unlike getter/setter method calls, property access remains fast.

// These are equivalent in performance:
$account->balance; // Direct property access via asymmetric visibility

// vs. the old pattern:
$account->getBalance(); // Method call (slightly slower)

3. Improved JIT compiler & performance

What's new in PHP 8.4's JIT

PHP 8.4 refines the Just-In-Time compiler introduced in 8.0, with better heuristics for when to JIT-compile code paths. The improvements focus on:

Function inlining for common operations
Better loop optimization for data processing
Improved branch prediction in hot code paths

Enabling and configuring JIT

; php.ini
opcache.jit=tracing        ; JIT mode: tracing (default), function, or disable
opcache.jit_buffer_size=256M ; Buffer for JIT code (256MB typical)
opcache.jit_debug=0        ; Set to 32 for debugging output

Measuring real impact

// Benchmark: Prime number sieve
function sieve(int $limit): int
{
    $primes = array_fill(2, $limit - 1, true);
    for ($i = 2; $i * $i <= $limit; $i++) {
        if ($primes[$i]) {
            for ($j = $i * $i; $j <= $limit; $j += $i) {
                $primes[$j] = false;
            }
        }
    }
    return array_sum($primes);
}

// Without JIT: ~450ms
// With JIT (PHP 8.4): ~45ms
// Speedup: ~10x for compute-heavy workloads

echo sieve(100000);

When JIT makes a difference

✓ Heavy computation: Image processing, cryptography, data analysis
✓ Loops over large datasets: Bulk import/export, reporting
✓ Real-time operations: WebSockets, high-frequency trading data

✗ I/O-bound applications: Database-heavy web apps (network is the bottleneck)
✗ Typical CRUD operations: Framework overhead masks JIT benefits

JIT Configuration Best Practices

; Production (CPU-bound)
opcache.jit=tracing
opcache.jit_buffer_size=256M
opcache.enable=1

; Shared Hosting (conservative)
opcache.jit=function       ; Lower overhead
opcache.jit_buffer_size=64M

; Development (debugging)
opcache.jit=disable        ; Full control for debugging

4. New `#[Override]` Attribute

Purpose & Syntax

The #[Override] attribute explicitly marks when a method overrides a parent method, enabling the IDE and static analyzer to catch accidental signature mismatches.

class Payment
{
    public function process(Order $order): bool
    {
        return true;
    }
}

class StripePayment extends Payment
{
    #[Override]
    public function process(Order $order): bool
    {
        // Stripe-specific logic
        return true;
    }
}

class BuggyPayment extends Payment
{
    #[Override]
    public function Process(Order $order): bool // ❌ Method name doesn't match
    {
        return true;
    }
}
// Error: Method Process() doesn't override parent method process()

Real-World Scenario

interface PaymentProcessor
{
    public function charge(Money $amount): Receipt;
}

class PayPalProcessor implements PaymentProcessor
{
    #[Override]
    public function charge(Money $amount): Receipt
    {
        // Implementation
    }

    // Typo caught at static analysis time:
    #[Override]
    public function chrage(Money $amount): Receipt // ❌ Misspelled
    {
        // This won't run—caught as override error
    }
}

5. Deprecations & Breaking Changes You Need to Know

`implode()` Parameter Order

Deprecated: Using implode($array, $glue) (array first).

// ❌ Old order (still works but deprecated)
$csv = implode($data, ',');

// ✅ Correct order (consistent with join)
$csv = implode(',', $data);

Stricter `preg_*` Return Types

Regular expression functions now have explicit return types. Code relying on loose comparison may break:

// ❌ This fails in PHP 8.4
if (preg_match('/pattern/', $string) == 1) {
    // ...
}

// ✅ Explicit comparison
if (preg_match('/pattern/', $string) === 1) {
    // ...
}

`ReflectionProperty` Changes

Access to properties via Reflection respects visibility rules more strictly in 8.4:

class Secret
{
    private string $value = 'hidden';
}

$obj = new Secret();
$prop = new ReflectionProperty(Secret::class, 'value');

// ❌ Throws error in 8.4 (no setAccessible)
$prop->setValue($obj, 'changed');

// ✅ Must be explicit
$prop->setAccessible(true);
$prop->setValue($obj, 'changed');

Prepare for PHP 9.0

Several functions are marked as "will be removed in PHP 9.0":

get_class() without arguments
get_parent_class() without arguments
Global is_* type check functions (migrate to instanceof where possible)

6. Best Practices for Adopting PHP 8.4

Migration Checklist

- [ ] Run `php -l` on all files to check syntax
- [ ] Update composer.json: "php": "^8.4"
- [ ] Test with deprecation warnings: error_reporting(E_ALL)
- [ ] Run static analysis (PHPStan, Psalm) with PHP 8.4
- [ ] Update CI/CD pipeline to PHP 8.4
- [ ] Test in staging before production
- [ ] Review deprecation notes in RFC documents

Typing & Property Hooks Strategy

If you're upgrading Laravel or Symfony projects:

// ❌ Old cast-based approach
class User extends Model
{
    protected $casts = [
        'email_verified_at' => 'datetime',
        'is_admin' => 'boolean',
    ];
}

// ✅ New approach with property hooks (PHP 8.4+)
class User
{
    private string $email;
    private bool $isAdmin = false;
    private ?DateTimeImmutable $emailVerifiedAt = null;

    public string $email {
        get => $this->email;
        set => $this->email = filter_var($value, FILTER_VALIDATE_EMAIL) 
            ? $value 
            : throw new InvalidArgumentException('Invalid email');
    }

    public bool $isAdmin {
        get => $this->isAdmin;
    }
}

Code organization with asymmetric visibility

Refactor existing getter/setter pairs:

// Before (5 methods)
class Price
{
    private float $cents;

    public function getUsd(): float { return $this->cents / 100; }
    public function setUsd(float $usd): void { $this->cents = (int)($usd * 100); }
    
    public function getCents(): int { return $this->cents; }
    public function setCents(int $cents): void { $this->cents = $cents; }
    
    public function add(float $amount): void { $this->cents += (int)($amount * 100); }
}

// After (cleaner, enforced invariants)
class Price
{
    public function __construct(
        private int $cents = 0,
    ) {}

    public float $usd {
        get => $this->cents / 100;
        set => $this->cents = (int)($value * 100);
    }

    public private(set) int $cents {
        get => $this->cents;
    }

    public function add(float $amount): void
    {
        $this->cents += (int)($amount * 100);
    }
}

Frequently Asked Questions

Q1: Is PHP 8.4 backwards compatible with PHP 8.3?

A: Mostly yes. The main breaking changes are:

implode() parameter order (deprecated, generates E_DEPRECATED)
preg_* stricter return types (may break loose comparisons)
Reflection visibility enforcement (requires explicit setAccessible())

For most projects, upgrading is straightforward if you're already on PHP 8.3. Test thoroughly in staging first.

Q2: Should I rewrite all my getter/setter methods to use property hooks?

A: No. Use property hooks for:

Simple computed properties
Validation on write
Lazy loading

Keep explicit methods for:

Complex business logic
Side effects (logging, events)
Database operations

A mixed approach is normal and healthy.

Q3: Does enabling JIT hurt performance?

A: No. JIT is transparent—it only helps. If it doesn't help a particular code path, PHP simply doesn't JIT-compile it. The overhead is minimal (a few MB of additional memory for the JIT buffer).

Worst case: disable it if you hit memory constraints. Best case: 2-10x speedup on CPU-bound workloads.

Q4: How do I enforce the `#[Override]` attribute in my team's code?

A: Use PHPStan or Psalm with strict rules:

# PHPStan with level 9
vendor/bin/phpstan analyse --level=9 src/

# Psalm
vendor/bin/psalm --strict-types

Both tools will flag missing #[Override] attributes and signature mismatches.

Q5: What's the recommended PHP version for new Laravel/Symfony projects in 2024?

A: Start with PHP 8.3 minimum, PHP 8.4 preferred if your hosting supports it. Most major frameworks officially support both:

Laravel 11+: PHP 8.2+
Symfony 7+: PHP 8.2+

Property hooks and asymmetric visibility are best used in new projects or major refactors. Legacy codebases benefit more from gradual adoption.

Conclusion: making the move to PHP 8.4

PHP 8.4 doesn't disrupt your workflow like PHP 8.0 did, but it solves real problems that developers face every day: verbose property boilerplate, inflexible access control, and performance bottlenecks in compute-heavy operations.

The three features to prioritize:

Property hooks reduce boilerplate and improve code clarity—start with new classes
Asymmetric visibility enforces intentional API design—refactor when you touch existing classes
JIT improvements pay for themselves in CPU-bound workloads—enable in production for compute-heavy apps

Your upgrade path is clear: move to PHP 8.4 when your infrastructure allows (hosting, CI/CD, team readiness), test thoroughly, and adopt new features incrementally as you refactor.

Ready to upgrade? Start with a non-critical service. Run static analysis. Measure performance. Share what you learn.