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` 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. > 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
