> Am 18.07.2016 um 23:37 schrieb Leonardo Pessoa via swift-evolution > <[email protected]>: > > Sealed methods can be overriden inside the defined module/library but > not outside. Same benefit of classes.
Interesting how the supporters of the proposal seem to imply that the opponents of the proposal don't get the difference between sealed and final. This has happened more than once here. I know that sealed and final are different, but still I think that sealed has no proper use case that cannot be achieved with final as well (and more elegantly so). Interestingly, no one has yet created a simple example with more than 60 lines of code that demonstrates the use of sealed, and why it is better than final. (Not counting contrived examples with class names like `SomeClass` and similar method names.) I guess that you will not find such a use-case. But who should prove this? Do the opponents of the proposal have to prove that there is no single good use case? Or should the supporters at least demonstrate 2 good use cases (again, non-contrived examples with more than 60 lines of code.) If the supporters are not able to make some good example code with sealed/open, the library developers of the future will not either. I agree with everything Garth said below. I hope for a miracle that the core team will see soon that SE-0117 should be deallocated fast ;) I'm sure we will all learn this in a year or two, when there will be experience with the sealed implementation. -Michael > > L > > > On 18 July 2016 at 16:32, Garth Snyder via swift-evolution > <[email protected]> wrote: >>> Nevin/Garth, please remember final and sealed are two different >>> concepts: final prevents anyone from subclassing/overriding while >>> sealed prevents from subclassing/overriding *outside* the module they >>> are declared. Thus final is not the same as sealed. >> >> No, of course it isn’t. I could well be misguided, but I don’t think I’m >> disoriented. :-) >> >> Ultimately, the question is whether sealed methods offer any additional >> utility or advantage beyond that of sealed classes plus final. The existence >> of “final” is certainly relevant, as it already provides some, but not all, >> of the features of method-level sealing. >> >> I’d still like to see a really solid use case that requires the full >> semantics of sealing at the method level. >> >> Garth >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
