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
