[swift-evolution] Final by default for classes and methods
Craig Cruden
ccruden at novafore.com
Wed Dec 23 12:50:53 CST 2015
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 <matthew at anandabits.com> wrote:
>
>
>> On Dec 23, 2015, at 12:43 PM, Craig Cruden <ccruden at novafore.com <mailto:ccruden at 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 at swift.org <mailto:swift-evolution at 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’.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151224/a3d1c578/attachment.html>
More information about the swift-evolution
mailing list