Re: [RFC] Polling API

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