Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125748
Precedence: bulk
MIME-Version: 1.0
Date: Fri, 04 Oct 2024 16:48:33 +0200
To: Valentin Udaltsov <udaltsov.valentin@gmail.com>
Cc: php internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] Asymmetric visibility Reflection API problems
In-Reply-To: <CAPyeZ4ML6nvmGWwH=p8Dko-mnPV1-tcgs7EF_P7yA-X_KLHpsA@mail.gmail.com>
References: <CAPyeZ4ML6nvmGWwH=p8Dko-mnPV1-tcgs7EF_P7yA-X_KLHpsA@mail.gmail.com>
Message-ID: <efdc68878ee2fb7230553be044830b51@bastelstu.be>
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

Hi

This thread is a good example why RFCs with a large impact should 
ideally be implemented well in advance of feature freeze.

Am 2024-10-03 15:32, schrieb Valentin Udaltsov:
> Here's why it works this way. Internally properties with symmetric
> visibility do not have an asymmetric flag. That is
> why `private private(set)` and `private` both have `isPrivateSet() =
> false`. Readonly properties without explicit `set`
> imply `protected(set)` [4] and thus they are symmetric when protected
> and asymmetric otherwise. I personally don't
> agree that Reflection API should stick to the internal implementation
> details. On the contrary, it should hide them and
> make it easier to study the facts about the code.

I agree. The RFC specifies:

>  The ReflectionProperty object is given two new methods: 
> isProtectedSet(): bool and isPrivateSet(): bool. Their meaning should 
> be self-evident.

Clearly it's not self-evident, and I would intuitively expect that a 
`protected Type $name` property is `isProtectedSet()`, because it 
clearly is protected set.

> - `ReflectionProperty::isPublic()` returns `true` only if the property
> is symmetrically public. For `public readonly $prop`
> it will return `false`, because it's implicitly `public protected(set)
> readonly $prop`. This is a BC break, but a
> smaller one, given that libraries now take "readonly" into account.

With this I disagree. The hydrator / code generation use case you 
mention is generally intimately tied to the capabilities of a given PHP 
version. Any new feature in PHP can affect the behavior of such code and 
thus needs to be evaluated to see if it needs to be taken into account 
to ensure correct behavior and asymmetric visibility is no different. I 
would not expect my Hydrator to work correctly with a new PHP version, 
unless specifically marked as compatible by the author.

Best regards
Tim Düsterhus