The “module” in this case being the same source file. i.e. Family.scala
contains a sealed class called “Parent” which is sealed, you could have another class in their called “Child” which inherits from the parent. but you cannot write another class and inherit from it in Sibling.scala. Since only the library writer has access to Family.scala and the classes are sealed by default - it is effectively the same as final by default other than it does not restrict the actual writer of the library not to inherit from their own class. > On 2015-12-24, at 1:45:45, Matthew Johnson <matt...@anandabits.com> wrote: > > >> On Dec 23, 2015, at 12:43 PM, Craig Cruden <ccru...@novafore.com >> <mailto:ccru...@novafore.com>> wrote: >> >> I thought sealed and final were effectively the same thing for production >> code, which is why it confuses me when you say final is right anything less >> including sealed is not. >> >> In Scala at least sealed is final with the exception that subclasses within >> the same source file are allowed. When it is compiled and shipped - you can >> no longer modify that source file….. > > They are not at all the same. The difference is that with sealed you cannot > inherit from classes in other modules which are not explicitly marked > `inheritable`, but you can inherit from classes in your own module that are > not explicitly marked `inheritable`. That is a big difference. > >> >> >>> On 2015-12-24, at 1:36:01, Matthew Johnson via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> >>> I strongly feel that I shouldn’t pay a price in production code in order to >>> better support those use cases. IMO ‘final’ is the right default for >>> production code and we pay a price if the default is anything less, >>> including ‘sealed’. >> >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
