> On Dec 23, 2015, at 3:21 PM, Tino Heth <2...@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.
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
