Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126505
Feedback-ID: i35d941ae:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Tue, 25 Feb 2025 15:13:54 -0600
To: internals@lists.php.net
Message-ID: <0b408765-04c4-49ed-bd5a-bceb34a2a3f1@app.fastmail.com>
Subject: [PHP-DEV] Consensus gathering: allowing unsetting of backed property hooks
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
From: tight.fork3192@fastmail.com

Hello! I started GitHub issue requesting that property hooks be allowed to be `unset()`: https://github.com/php/php-src/issues/17922

While discussing in the issue it was suggested I pitch this to the mailing list, so here I am.

You can review the GitHub issue so I won't rehash the whole thing here, but I'll summarize the main points for `unset()` of backed property hooks:

1. It is well-established in PHP that one can `unset()` object properties. If we cannot `unset()` property hooks - which to a consumer are indistinguishable from plain properties - then the consumer must now be aware of the object's internal implementation before doing what used to be explicitly allowed. This is both poor encapsulation and not compatible with the commonly-understood behavior of `unset()`, leading to surprising cases where a consumer of an object could cause a fatal error by trying to `unset()` a property that unbeknownst to them is implemented as a property hook.

2. Getters may perform a calculation, or fetch from a database, and cache the result in the backing value, but without `unset()` we can end up in a state where the logic to determine that value can never be executed again. The workaround is exposing a public method that contains such logic, but that defeats the point of putting logic in property hooks in the first place, and exposes internal class implementation details that should not concern the consumer. Getting and caching values is a common case in ORM layers, one of the biggest users of PHP.

3. It would be convenient to be able to `unset()` backed properties when changing data elsewhere in a class, for example to trigger a recalculation or re-fetching from the database. It's not enough to set such properties to `null` because 1) the actual type of the property may in fact not be nullable, leading to inconsistency in the property's PHP type and the database column type, and 2) in practice `null` is a real value that can come from the database, which is a distinct concept from "uninitialized at the PHP level". (This is the old `isset()` vs `is_initialized()` problem, a tired struggle going on decades now.)

Some arguments raised against were internal implementation details; that `unset()` itself is a bad design choice so we should not cater to it; and that catering to `uninitialized` makes typing more complex.

I can't comment on implementation details. 

To the last two points, I would say that for better or worse, `unset()` and `uninitialized` are part of PHP and I assume they're here to stay. Therefore if we're extending the language, we should extend it in ways that embrace, not ignore, its warts, because they're what make the language and they're what decades of developers are accustomed to. Ignoring the warts, or leaving them in the language but calling them bad practice that must be avoided, results in footguns and a language that is inconsistent with itself. (As I'm sure you're all aware, inconsistency is one of the favorite charges leveled at PHP by its detractors.)

And while `uninitialized` may make types more complex, it can often be very useful, especially when filling objects from database rows - one of the most common tasks a web developer will ever do. It might be technically purer to require that objects only be created with lengthy constructors that initialize every property with strongly typed values, and `unset()` and `isset()` never be used, but for better or worse that's just not how PHP evolved. Having the flexibility of objects with uninitialized, and therefore unsettable, properties is very useful. This flexibility is part of what makes PHP so attractive and what made it so popular in the first place.

In the GitHub thread it was mentioned that an RFC would be required. I've never written one, nor am I familiar with PHP internals, but I can try putting one together if there's interest.