{"id":151,"date":"2026-04-25T13:03:17","date_gmt":"2026-04-25T13:03:17","guid":{"rendered":"https:\/\/abrarqasim.com\/blog\/php-84-asymmetric-visibility-when-i-actually-use-it\/"},"modified":"2026-04-25T13:03:17","modified_gmt":"2026-04-25T13:03:17","slug":"php-84-asymmetric-visibility-when-i-actually-use-it","status":"publish","type":"post","link":"https:\/\/abrarqasim.com\/blog\/php-84-asymmetric-visibility-when-i-actually-use-it\/","title":{"rendered":"PHP 8.4 Asymmetric Visibility: When I Actually Use It (And When I Don’t)"},"content":{"rendered":"

I’m going to admit something. When I first read the PHP 8.4 asymmetric visibility RFC<\/a> I thought: “Cool, another feature I’ll read about, nod at, and never use.” Three weeks into 8.4 I’ve used it maybe twenty times. So if you’re the same flavor of skeptic, let me try to change your mind with code, not slogans.<\/p>\n

This is a short feature with an outsized effect on how DTOs and value objects look. I’ll show the before, the after, the three situations where I reach for it, and the one case where I still prefer a getter method.<\/p>\n

What asymmetric visibility actually is<\/h2>\n

One sentence: a property can now have different visibility for reading and writing.<\/p>\n

public private(set) string $name;\n<\/code><\/pre>\n
Read $obj->name<\/code> from anywhere. Write $obj->name = ...<\/code> only from inside the class. That’s it. No getter method. No readonly<\/code> trick. No constructor-only escape hatch. You can still mutate the property inside the class; you just can’t mutate it from outside.<\/p>\n
The supported combinations are public<\/code>, protected<\/code>, and private<\/code> for set<\/code>, and any visibility for the read side. The PHP core team shipped this alongside property hooks in 8.4, and the pair covers maybe 80% of what people historically wrote boilerplate getters and setters for. The official PHP 8.4 release notes<\/a> have the full list if you want the bird’s-eye view.<\/p>\n
The before code (you’ve written this exact class)<\/h2>\n
Every PHP codebase I’ve ever seen has dozens of these. A simple entity with a getter-only public API:<\/p>\n
\/\/ before: boilerplate getter, mutable internal field\nfinal class Order\n{\n    private string $status = 'pending';\n\n    public function getStatus(): string\n    {\n        return $this->status;\n    }\n\n    public function markPaid(): void\n    {\n        $this->status = 'paid';\n    }\n}\n\n$order = new Order();\necho $order->getStatus();   \/\/ 'pending'\n$order->markPaid();\necho $order->getStatus();   \/\/ 'paid'\n<\/code><\/pre>\n
Nothing wrong with this. It works. It just has a getter method that does nothing except return a private field, and every consumer has to remember to call ->getStatus()<\/code> instead of ->status<\/code>. Multiply by thirty fields and you’re looking at a file full of one-line methods.<\/p>\n
The readonly<\/code> keyword from PHP 8.1 got us partway there, but readonly only lets you set the property in the constructor. If the property changes over the object’s lifetime (like status<\/code> above, which transitions from pending to paid to refunded), readonly<\/code> is useless.<\/p>\n
The after code, with asymmetric visibility<\/h2>\n
Same class, rewritten:<\/p>\n
\/\/ after: asymmetric visibility does the work\nfinal class Order\n{\n    public private(set) string $status = 'pending';\n\n    public function markPaid(): void\n    {\n        $this->status = 'paid';\n    }\n}\n\n$order = new Order();\necho $order->status;        \/\/ 'pending', public read\n$order->markPaid();\necho $order->status;        \/\/ 'paid'\n$order->status = 'paid';    \/\/ Fatal error: cannot modify private(set) property\n<\/code><\/pre>\n
The getter is gone. Consumers read $order->status<\/code> directly. External writes are a fatal error. The class still mutates the field internally through markPaid()<\/code>. The public surface is smaller and honest: if you read the class definition, you can see exactly which fields are externally mutable and which aren’t.<\/p>\n
I grep’d a medium-sized Laravel codebase for function get.*(.*).*return \\$this-><\/code> and found 431 methods that were one-line getters over private fields. Not every one of those is a candidate, but most are. That’s a lot of boilerplate to delete.<\/p>\n
The three situations where I reach for it<\/h2>\n
1. DTOs and value objects<\/h3>\n
Immutable-ish data carriers that get populated once and read many times. Perfect fit. The public private(set)<\/code> pattern replaces a constructor-heavy builder and a pile of getters with a clean field list.<\/p>\n
final class UserProfile\n{\n    public function __construct(\n        public string $id,\n        public private(set) string $email,\n        public private(set) DateTimeImmutable $createdAt,\n    ) {}\n\n    public function updateEmail(string $new): void {\n        $this->email = $new;   \/\/ still works from inside\n    }\n}\n<\/code><\/pre>\n
2. State machines with enforced transitions<\/h3>\n
Anything with a status<\/code> or state<\/code> field that should only change through approved methods. Exposing the field as public private(set)<\/code> means external code can inspect the state cheaply without bypassing the transition logic.<\/p>\n
3. Framework-internal mutable state<\/h3>\n
Things like request contexts, query builders, and middleware pipelines that accumulate state as they run. You want internal components to tweak the state freely, and you want downstream consumers to read the final state without accidentally poisoning it. Brent Roose’s writeup on what’s new in PHP 8.4<\/a> has a few more examples that pattern-match onto framework code if you want to see it in context.<\/p>\n
When I still write a getter method<\/h2>\n
Not every field wants this treatment. I still write an explicit getter when:<\/p>\n