[swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

[Xiaodi Wu]

On Sat, Jul 16, 2016 at 1:48 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:

> On Sat, Jul 16, 2016 at 1:16 PM, John McCall via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> On Jul 16, 2016, at 11:03 AM, T.J. Usiyan <griotspeak at gmail.com> wrote:
>>
>> "open is invalid on declarations that are not also public (see the
>> Alternatives discussion for rationale)."
>> +
>>
>> "If an open class inherits an open method from a superclass, that method
>> remains open. If it overrides an open method from a superclass, the
>> override is implicitly open if it is not final."
>>
>> I understand that the intent is probably not to say that subclasses are
>> public by default. My point is that those two statements, without an
>> explicit spelling out of the implicit access level, could lead me to
>> believe that subclasses are implicitly public by default. It is open to
>> interpretation. Neither the prose nor the code examples address it.
>>
>>
>> I see your general point.  I'll think about how to re-word this; it may
>> be sufficient to just remove the requirement that open methods appear in
>> open classes.  Suffice it for me to say now, officially, that this proposal
>> does not require classes to be public or open just because they override
>> open methods from an open superclass.
>>
>
> It might be barely sufficient solely to remove the requirement that open
> methods appear in open classes. However, if my subclass is internal, I
> shouldn't be required to declare a `public override` of an open method just
> to satisfy the rules for `open`, which would be forced by the rule that
> `open` is invalid on declarations that are not also `public` combined with
> the rule that overrides of an open method are by default open.
>
> This would degrade the developer experience significantly, since a
> beginning developer writing only internal subclasses for their own app
> would now be required to litter either `public override` or `final
> override` throughout their code in the ordinary course of subclassing. On
> reconsideration, it might be best if overrides are not implicitly open.
>

I should add: independent of the issue above for internal subclasses in
apps that don't vend an API having "public" overrides, it seems to me most
consistent with the general aim of the proposal that open overrides should
be marked as such by the subclass's owner. The same logic that requires
explicit use of `open` for subclass declarations should require them for
overridden methods. (Whereas, clearly, inherited methods that don't show up
at all in the code inside the subclass are a different ballgame.)


>
>
>> John.
>>
>>
>>
>> On Sat, Jul 16, 2016 at 1:35 PM, John McCall <rjmccall at apple.com> wrote:
>>
>>> On Jul 16, 2016, at 9:32 AM, Matthew Johnson via swift-evolution <
>>> swift-evolution at swift.org> wrote:
>>> Sent from my iPhone
>>>
>>> On Jul 16, 2016, at 10:59 AM, T.J. Usiyan via swift-evolution <
>>> swift-evolution at swift.org> wrote:
>>>
>>> Yes, sorry, my point was that this consideration isn't spelled out.
>>>
>>> Another question is whether or not making a subclass of an open class
>>> public by default is what we want. I see why it would be, I just think that
>>> it is a wrinkle to default to internal otherwise but not here.
>>>
>>>
>>> I can't think of any good reason to assume a specific class should be
>>> public just because it is a subclass of an open class.  The internal
>>> default would still be the right default in this case.
>>>
>>>
>>> Right, there's no new restriction here.  Of course you can make a
>>> private or internal subclass of a public open class — otherwise, you'd have
>>> to publicize every subclass of (say) UIViewController.
>>>
>>> John.
>>>
>>>
>>>
>>> On Sat, Jul 16, 2016 at 10:32 AM, Karl <razielim at gmail.com> wrote:
>>>
>>>>
>>>> > On 16 Jul 2016, at 16:10, T.J. Usiyan via swift-evolution <
>>>> swift-evolution at swift.org> wrote:
>>>> >
>>>> > What happens if I want an `internal` subclass of an `open` class?
>>>>
>>>> That should be allowable. You may want some optimised implementations,
>>>> similar to how Apple used class-clusters in Obj-C. I don’t think that same
>>>> pattern is exactly possible in Swift (I don’t think a class can set ‘self’
>>>> in its initialiser, or at least it couldn’t in Swift 1). But the same
>>>> principle applies - you may want a public class which you don’t allow
>>>> others to subclass, but you might have a static method or other function
>>>> which returns an internal optimised implementation.
>>>>
>>>> If you used a protocol rather than a concrete type in that case,
>>>> theoretically others could conform to it and throw their own objects back
>>>> at your code, which goes against the point of this proposal.
>>>>
>>>> We might think about creating ‘sealed’ protocols, too.
>>>>
>>>> Karl
>>>
>>>
>>> _______________________________________________
>>> 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/20160716/ddaa9951/attachment.html>