[swift-evolution] Final by default for classes and methods
matthew at anandabits.com
Wed Dec 23 20:15:04 CST 2015
> On Dec 23, 2015, at 3:21 PM, Tino Heth <2th at gmx.de> wrote:
>> I think it's best to keep this thread focused on classes. We can start a new thread for methods later if desired. But we should wait until the dust has settled on the classes conversation IMO.
> I disagree: The whole thread is not about practical implications but rather about general standpoints, so the discussion will be identical — and I foresee that this second thread would start with "now that we made classes final by default, it's just natural consequence to do the same with methods".
>>> Making `final` the default, or `sealed` the default, encourages the use of closed class hierarchies. It attempts to make inflexibility the preferred form of shared Swift code. I'm not sure that's the right thing to do.
>> I don't agree with this framing. IMO it encourages alternative designs emphasizing protocols and composition. This is a very good thing IMHO. I like to think of inheritance is a tool is last resort.
> The claim about inflexibility is to take with a grain of salt, but why do you think it is good to force your opinion on how flexibility should be achieved on others? Protocols and composition are useful without breaking inheritance, just leave the choice to the people.
I’m not trying to force my opinion on anyone. I’m just making a case for the advantages of a particular default. Changing the default does not break inheritance at all. Nobody has to use the default when it doesn’t fit the design they wish to implement.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution