[swift-evolution] [Proposal] Sealed classes by default

[John McCall]

> On Jul 1, 2016, at 10:51 AM, Michael Ilseman <milseman at apple.com> wrote:
> If “opened”, who or what did the opening? If “open” is like “extensible”, then I would interpret “opened” to be like “extended”.

Yeah, I would prefer "open" to "opened".

John.

> 
>> On Jul 1, 2016, at 10:35 AM, Leonardo Pessoa via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> The proposal was to use "sealed" so why not "opened"? I understand it
>> may not be common to use "opened" as an adjective but from the
>> dictionaries I consulted it is possible to.
>> 
>> opened class MyViewController: UIViewController {
>>      opened func displayMe(_ me: person) { … }
>> }
>> 
>> On 1 July 2016 at 13:47, John McCall via swift-evolution
>> <swift-evolution at swift.org> wrote:
>>> On Jul 1, 2016, at 12:23 AM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>>> That starts to look an awful lot like a fifth access level just for classes
>>> (I know you're not proposing one, but it could start to look that way to a
>>> user). I think there's much to be said for having the word public in front
>>> of things that are public. Unless, of course, your strawman keyword is a
>>> much maligned compound word that begins with "public", like
>>> "publicoverridable".
>>> 
>>> 
>>> I would also prefer a single keyword if the word implies something about
>>> accessibility.  "open" does that, although using it here would conflict with
>>> its potential use on enums unless we required all cases within the defining
>>> module to be present in the enum declaration rather than extensions.
>>> 
>>> I don't think we'd ever use a compound keyword that starts with public; we'd
>>> just separate them and say that the second half can only be present on a
>>> public declaration, or do this parenthesized syntax.
>>> 
>>> John.
>>> 
>>> 
>>> On Fri, Jul 1, 2016 at 01:54 Brent Royal-Gordon <brent at architechies.com>
>>> wrote:
>>>> 
>>>>> If we're going to go along those lines, we should just use
>>>>> public(subclassable) and public(overridable).  We can fall back on those if
>>>>> necessary; I would just like to continue looking for better alternatives.
>>>> 
>>>> I would prefer to have a *single* keyword which meant both public and
>>>> overridable. That would minimize the impact of this feature—instead of
>>>> writing:
>>>> 
>>>>       public class MyViewController: UIViewController {
>>>>               public func displayMe(_ me: person) { … }
>>>>       }
>>>> 
>>>> You'd write (strawman keyword):
>>>> 
>>>>       openseason class MyViewController: UIViewController {
>>>>               openseason func displayMe(_ me: person) { … }
>>>>       }
>>>> 
>>>> And then `MyViewController` could be subclassed, and `displayMe`
>>>> overridden.
>>>> 
>>>> --
>>>> Brent Royal-Gordon
>>>> Architechies
>>>> 
>>> 
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>