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 <s...@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 <s...@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@swift.org> wrote:
>>>
>>>> On Jul 1, 2016, at 10:51 AM, Michael Ilseman <milse...@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@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@swift.org> wrote:
>>>>>> On Jul 1, 2016, at 12:23 AM, Xiaodi Wu <xiaodi...@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 <br...@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@swift.org
>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>>>
>>>>> _______________________________________________
>>>>> swift-evolution mailing list
>>>>> swift-evolution@swift.org
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
