[swift-evolution] [swift-evolution-announce] [Review #2] SE-0117: Default classes to be non-subclassable publicly

[Károly Lőrentey]

> On 2016-07-20, at 19:34, John McCall <rjmccall at apple.com> wrote:
> 
> I agree that having the concept of "visible publicly but only arbitrary modifiable internally" adds complexity to the language.  However, once we've got non-open public classes — and as I understand it, you still support those — that complexity already exists.  You're not really eliminating anything by preventing this from being applied to methods.
> 
> Also, we're going to be proposing a lot of new things for library-resilience over the next six months or so that will add appreciable but unavoidable complexity to the language around module boundaries. Module boundaries have a lot of special significance in the language design because Swift takes the stable binary interface problem much more seriously than, I think, almost any other language can claim to.

Fair enough! Let’s move on.

>> This reminds me: Whether or not we allow the sealed level on methods, I suggest we provide a contextual keyword to (optionally) spell it. A "sealed" keyword is the obvious choice. This would encourage people to use common terminology, and makes it easier to use search engines to find an explanation of the concept. Autogenerated API summaries should add the "sealed" keyword.
> 
> Yes, we should probably add some way to spell it.  "sealed" does not feel like a natural opposite to "open", however, and I think we're quite taken with "open".  I would suggest "nonopen" or "closed”.

Ah, interesting! Kotlin and Scala uses the “sealed” keyword for their own variants for the same concept. C# is popular and uses “sealed” to mean what we call “final”; it’s in the same general ballpark. MATLAB (!!!) does the same. So it can be argued “sealed" is a somewhat common term of art for roughly this pattern. 

I could get used to “closed”, though.

But I think “nonopen” is a no-no (pen): it makes my eyes bleed.

-- 
Károly
@lorentey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160720/16af2841/attachment.html>