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

[Sean Heber]

Imma try again.. :P


- everything is sealed within its module by default, no keyword

- use “export” (formerly “public”) to mean “visible outside of the module, no subclassing or overriding externally, but overriding and subclasses allowed internally unless otherwise restricted”

- use “export(public)” to mean “visible outside of the module, subclass/overridable externally”

- using “export final” then makes sense with the “final” being applied internally to the module as well

- using “export(public) final” *probably* doesn’t make sense, but would mean overriding and subclasses allowed externally, but not internally 


My argument for “export” here is that it is in the inverse of “import” which is how you get another module’s stuff into your module in the first place.


Bonus side tracking:

I would then possibly argue that “internal” should be renamed to “public”.

After which I might be inclined to argue that “fileprivate” be renamed to “internal” :P

l8r
Sean



> On Jul 1, 2016, at 1:20 PM, Sean Heber <sean at fifthace.com> wrote:
> 
> Ok, I suppose that this design *basically* undoes the sealed by default thing, doesn’t it? :P  lol. One of those days, I guess..
> 
> Sigh.
> 
> Crawling away…
> 
> l8r
> Sean
> 
> 
>> On Jul 1, 2016, at 1:16 PM, Sean Heber <sean at fifthace.com> wrote:
>> 
>> Coming in late on this, but here’s my take guided by the principal of least surprise (according to me):
>> 
>> - everything is sealed within its module by default, no keyword
>> - use “public” to mean “exported out of the module, subclass/overridable”
>> - use “public(final)” to mean “exported out of the module, no subclassing or overriding externally, but overriding and subclasses allowed internally”
>> - meaning of “final” does not change
>> - using “public final” then means the same as both public(final) and also “final” internal to the module
>> - using “public(final) final” could be presented as an error with fixit since it’s redundant
>> 
>> Did I miss anything?
>> 
>> l8r
>> Sean
>> 
>> 
>> 
>>> On Jul 1, 2016, at 12:53 PM, John McCall via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>>> 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
>>>> 
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>