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
