Re: Re: [RFC][Draft] Sealed Classes

Hello Saif sob., 24 kwi 2021, 13:00 użytkownik Saif Eddin Gmati <azjezz@protonmail.com> napisał: > A major behavior i wanted to discuss is how should sealed interfaces work, > and specially around Throwable which is currently sealed to > only Error > and Exception, but allows other interfaces to extend it, and > other > classes to implement it as long as they extend Error or > Exception ( or > another class that does so ). > > As per the current proposal, if Throwable is to be declared > sealed, > permitting only Error and >Exception, it won't be possible to extend it, > resulting in a major BC-break, considering that too many libraries extend > this interface in their own ExceptionInterface. > > To work around this, there's two solution: > > 1. don't declare Throwable sealed and keep it as a special > case. > 2. interfaces declared sealed, can be extended by other interfaces, > however, classes that implement either the sealed interface directly, or > via another interface, have to extend one of the classes the sealed > interface permits. > > The second solution will allow declaring Throwable sealed, and > would > bring complete consistency between internally sealed symbols, and user > land, without any BC breaks, and IMHO, it doesn't hurt as at the end, no > one will be able to implement Throwable without extending the > permitted > classes. > I like the idea of sealed class along with proposed keywords which are similar to already existing in other languages like Java. Personally I'd go with the second option. Speaking of Attributes I prefer not to use an Attribute for any particular language feature which expects input arguments to be a valid class or interface name for two reasons: first because there is no effective way to restrict input string to be a valid class or interface name and second that it'd require passing strings which means in most cases passing class or interface name with magic ::class constant read. Cheers, Michał Marcin Brzuchalski