Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126374
Precedence: bulk
MIME-Version: 1.0
References: <087a01db596a$e7525660$b5f70320$@glaive.pro> <045501db7b37$e1f15970$a5d40c50$@glaive.pro>
In-Reply-To: <045501db7b37$e1f15970$a5d40c50$@glaive.pro>
Date: Tue, 11 Feb 2025 17:32:46 +0100
Message-ID: <CAPyj-LDDHVaos9LNj4Y7qVSsNTMcHbpZiRST3cfDPNnnJaK28Q@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Optional interfaces
To: php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: tovilo.ilija@gmail.com (Ilija Tovilo)

Hi Juris

On Sun, Feb 9, 2025 at 10:16=E2=80=AFPM Juris Evertovskis <juris@glaive.pro=
> wrote:
>
> https://wiki.php.net/rfc/optional-interfaces

Thanks for your efforts.

I've reviewed the patch, it seems there are still a few issues and it
would be great if we could solve them before this goes into voting.

A few thoughts on the RFC itself:

You mention `#[Override]` in the RFC and how it will work on optional
interfaces that are available at runtime (the `TestClass::method()`
example). Given the interface is implemented as optional, it is to be
expected that the interface will go away under certain configurations.
This will break, because the method is no longer overridden. Hence, it
might be best to also disallow `#[Override]` on optional interface
methods, to signal the breaking for the missing interface scenario.

>  A class only conforms to types that are actually implemented.

Just as a note, this also has some semantic implications. Notably
`$object instanceof OptionalInterface` will evaluate to `false`
without errors when the interface goes missing. To catch this issue
with static analysis, the project will need to be analysed without the
interface being available, or they will need to gain new rules that
catch such expressions that can lead to inconsistent results.

Also, when I read the subject "optional interfaces", what came to mind
was "an interface that may or may not be implemented", i.e. similar to
Objective-C's optional protocol methods [1]. I'm not sure if the
naming can be improved.

Overall, I'm not particularly convinced this is a big problem that
needs solving, but I'll leave that up to framework designers to
decide.

Ilija

[1] https://developer.apple.com/library/archive/documentation/Cocoa/Concept=
ual/ProgrammingWithObjectiveC/WorkingwithProtocols/WorkingwithProtocols.htm=
l#//apple_ref/doc/uid/TP40011210-CH11-SW6