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

[Xiaodi Wu]

Makes sense. Thanks for clarifying.


On Sat, Jul 16, 2016 at 14:17 John McCall <rjmccall at apple.com> wrote:

> On Jul 16, 2016, at 11:48 AM, 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`
>
>
> This rule only applies to explicit uses of "open".  A method that is
> implicitly open due to overriding does not have this restriction.
>
> In general, my intent in writing this proposal was to cover the important
> interactions, not to write a fully precise specification.  The general rule
> about overrides having to be at least as accessible as the minimum of their
> class and their overridden method still applies, superseded only by the
> rule that it is acceptable to drop the "open" on a public open override.
>
> 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 continue to think "override" is sufficient communication here.  We're
> not going to have a model where the inherited open API of the superclass
> becomes non-open in the subclass.  We don't want the mere existence of an
> override in the subclass to change that because it's a fairly core goal
> that the existence of an override (at least one which doesn't covariantly
> refine the type) in a subclass should not affect source/binary
> compatibility.
>
> John.
>
>
>
>
>> 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/a21ae6fe/attachment.html>