Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126188
Message-ID: <f44f2387-62cf-4c72-ae23-e4d7979f1c8f@gmail.com>
Date: Sun, 29 Dec 2024 13:29:35 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [RFC] [Discussion] Optional interfaces
To: internals@lists.php.net
References: <087a01db596a$e7525660$b5f70320$@glaive.pro>
Content-Language: en-US
In-Reply-To: <087a01db596a$e7525660$b5f70320$@glaive.pro>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: dossche.niels@gmail.com (Niels Dossche)

On 28/12/2024 21:56, Juris Evertovskis wrote:
> Hi,
> 
>  
> 
> I would like to propose a new syntax that let’s you implement an interface only if it exists.
> 
>  
> 
> `class MyClass extends ?OptionalInterface {}`
> 
>  
> 
> If the `OptionalInterface` exists, the class implements it. If no such interface can be found, it is ignored.
> 
>  
> 
> https://wiki.php.net/rfc/optional-interfaces <https://wiki.php.net/rfc/optional-interfaces>
> 
>  
> 
> The need to declare compatibility with a certain interface without requiring the interface itself comes up when you’re writing code that should work with various versions of other libraries or PHP itself and when a library provides interoperability with some other library or a PHP extension, but does not require it.
> 
>  
> 
> Although this would mainly be used by library developers, the consumers of those libraries would also benefit as this syntax would clearly communicate the intention of optional interoperability. IDEs and static analysis tools could also have easier time with `?OptionalInterface` instead of class definitions inside an `if (interface_exists(…)) { … } else {…}`.
> 
>  
> 
> I’ve not entirely sure about the naming as an “optional interface” feels like an oxymoron. I’ve also considered names like non-required interfaces, conditional interfaces, optional/conditional implementation or even soft interfaces/soft implementation. Please let me know if the naming itself bothers you.
> 
>  
> 
> Previous discussion: https://externals.io/message/125967 <https://externals.io/message/125967>
> 
> WIP implementation: https://github.com/php/php-src/pull/17288 <https://github.com/php/php-src/pull/17288>
> 
>  
> 
> Looking forward to your feedback and suggestions!
> 
> Juris
> 

Hi

I've left some remarks on your PR to help you further with the opcache stuff.
This should fix the tests and answer some questions.
I also left a concern regarding the caching, and in particular I'm thinking about the inheritance cache. I'll copy it here:

Suppose this scenario:
1. You do a request and an optional interface is not available, this class is cached without that interface.
2. A future request comes in, and reuses the cache, but since this may be via a different code path it's possible that the interface is now available. Yet because the class was cached, this won't implement the interface now even though it's available at this point in time. I'm not entirely sure if this is a real problem but it should be checked. I also don't know what assumptions in the engine this may break.

Kind regards
Niels