Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130508
Precedence: list
MIME-Version: 1.0
Date: Tue, 31 Mar 2026 11:23:50 +0200
To: Jakub Zelenka <bukka@php.net>
Cc: PHP internals list <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] Polling API
In-Reply-To: <CAEKnhAEDCGbM6RpqpAT=f_tP4Z239z7_Xbe8_0ZimC3FeziF1A@mail.gmail.com>
References: <CAEKnhAFZXqWH20Cy2g6-0c2V1Vd4w-N0M4xefzt6tTEp90+LqQ@mail.gmail.com>
 <926a26a6-eb89-49aa-a387-6cc79caa29c1@bastelstu.be>
 <CAEKnhAE91_qMYRTBpdY_FETV4J_SjonAvK0LqnfyAA81nQEftA@mail.gmail.com>
 <b9791d4632ebaa247fe8c4e541ee642a@bastelstu.be>
 <CAEKnhAEDCGbM6RpqpAT=f_tP4Z239z7_Xbe8_0ZimC3FeziF1A@mail.gmail.com>
Message-ID: <d76f56bb16e880292d23f4ecc34f65fb@bastelstu.be>
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

Hi

Sorry for the late feedback, it's hard juggling all the different RFCs 
that are in progress to provide meaningful feedback.

Am 2026-03-11 22:07, schrieb Jakub Zelenka:
>> > I also think that there is not really much use case for user space to
>> > implement their own handles so such interface would be used only
>> > internally
>> > anyway.
>> 
>> This applies equally to interfaces and abstract methods. The abstract
>> base class however will make it much weirder when a specific (future)
>> handle might need to implement additional interfaces or abstract
>> classes.
>> 
>> > In addition interface would effectively expose the internal stream fd
>> > which
>> > is currently hidden and makes harder messing up with stream fd which
>> > might
>> > cause various issues.
>> 
>> I don't understand that point. For both an interface and an abstract
>> method, the method would exist on the child class and thus can be 
>> called
>> by a developer.
>> 
>> 
> Well if it is abstract, then the method can be protected and because 
> the
> classes are final, user spaces cannot call it. But for interface I 
> would

Protected methods of internal classes should still be accessible to 
Reflection.

> need to make it public which means that StreamHandle would need to 
> expose
> callabable (public) method. I know that I could just return 0 and use
> different handling internally but I think this would be surprising and
> created obvious inconsistency. I mean it's fine if the calls happen
> internally but if the exposed methods are just dummy and return 
> nonsense
> for user space, then I don't think it would be a good design.

It's equally weird that there is a protected method that is effectively 
internally called by an unrelated class (Context) that is not supposed 
to know about it. Perhaps the correct solution would then be removing 
the `getFileDescriptor()` method from the public API entirely and change 
`Handle` to be an empty “marker interface” that cannot be implemented in 
userland (similarly to Throwable) to leave all options open for the 
future?

Best regards
Tim Düsterhus