Re: Asymmetric visibility Reflection API problems

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