Re: [RFC] [Vote] Adding return types to internal methods
Hey Máté, NikiC,
On Thu, Apr 22, 2021 at 12:15 PM Máté Kocsis <kocsismate90@gmail.com> wrote:
> Overall, I see the change of reported ReflectionMethod#getReturnType()
>> as non-problematic, and tooling around reflection would continue working as
>> expected, while adding new API requires:
>>
>
> I do think it would be problematic, and a new API is a must (either the
> one Nikita asked about or the current one). Let's consider a
> reflection-based static analyser: in PHP 8.1, it would report the
> incompatible
> user-land return types as a very serious issue all of a sudden, while in
> fact it's not the case yet.
>
> (now I see that Nikita answered the same)
>
> Máté
>
No, that's not serious: type-checkers operate pre-runtime, so it is good
that they proactively report a variance issue when a subtype of an
interface is not restrictive on a return types.
Compared to the effort to be added to support the new behavior **at
runtime**, this is a non-problem.
Current static analyzers already report issues like these, and already rely
on ReflectionMethod#isInternal() to determine if they should care or not
about a missing type declaration (hence no need for a new API).
Examples:
* https://phpstan.org/r/530583f0-fab5-4f46-af6b-332e67b862cf
* https://psalm.dev/r/7f987b25a3
In fact, a lot of tooling treats Reflection*#isInternal() as a huge red
flag that means "here be dragons", which is more than sufficient to move
ahead :-)
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
Thread (13 messages)