[swift-evolution] [Proposal] Sealed classes by default
Jose Cheyo Jimenez
cheyo at masters3d.com
Fri Jul 1 15:09:15 CDT 2016
I almost sent out an email with what you wrote.
how about `public( nonfinal )`
> - use “public(nonfinal)” to mean “exported out of the module, subclass/overridable”
I think just `open` would be a little bit better. `public( open )`
> On Jul 1, 2016, at 11:20 AM, Sean Heber via swift-evolution <swift-evolution at swift.org> 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
>>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160701/f3f36a84/attachment.html>
More information about the swift-evolution
mailing list