Hi, On Tue, Mar 31, 2026 at 3:24 PM Jakub Zelenka <[email protected]> wrote:
> Hi, > > On Tue, Mar 31, 2026 at 11:23 AM Tim Düsterhus <[email protected]> wrote: > >> 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. >> >> > Good point. > > >> > 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? >> >> > This (marker interface just for internal classes) is actually a really > good idea. Will change it. > > I just implemented this and it's much better so thanks for this. RFC updated as well.
