Makes sense. Thanks for clarifying.
On Sat, Jul 16, 2016 at 14:17 John McCall <[email protected]> wrote: > On Jul 16, 2016, at 11:48 AM, Xiaodi Wu <[email protected]> wrote: > On Sat, Jul 16, 2016 at 1:16 PM, John McCall via swift-evolution < > [email protected]> wrote: > >> On Jul 16, 2016, at 11:03 AM, T.J. Usiyan <[email protected]> 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 <[email protected]> wrote: >> >>> On Jul 16, 2016, at 9:32 AM, Matthew Johnson via swift-evolution < >>> [email protected]> wrote: >>> Sent from my iPhone >>> >>> On Jul 16, 2016, at 10:59 AM, T.J. Usiyan via swift-evolution < >>> [email protected]> 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 <[email protected]> wrote: >>> >>>> >>>> > On 16 Jul 2016, at 16:10, T.J. Usiyan via swift-evolution < >>>> [email protected]> 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 >>> [email protected] >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >>> >>> >> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
