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

[Andre Elder]

2016/07/15 16:37、Riley Testut via swift-evolution <swift-evolution at swift.org> のメッセージ:

> FWIW, I'm still against this proposal, but since it will be accepted regardless, here are my thoughts:
> 
> • Open keyword is significantly better. 
> • Members should be *open* by default, and final should be opt-in. If you're opening up a class for subclassing, my gut says you should allow the client to do as they wish.
If you have a class that was not open yet, just making it open wouldn't expose any members: it would then just be subclassable.

If the act of making the class open doesn't implicitly make overriding possible, well all you can do then is add methods, and that can be done with extensions anyways, so it's not as useful and makes the public open class {} pattern just by itself not so useful imho... 😬

Also, the keyword 'open' itself may imply 'hey I'm open, please do what you want with my public members', whereas 'subclassable' is more specific in intention...  (but that's just me, so n=1 and all that)

TLDR; +1 to the above: simpler is better and defaulting to overridable for public members on an open class is simpler... invariants can be protected by the 'final' keyword.

If we were to default to non-overridable, a more consistent 'open' on the method is preferred over overridable for me... open class, open method... much better imho...

>  If only one or two methods should be overridable, I think delegation (via protocols) is a much better solution.

Delegation and protocols all the way!

> • I feel like final and open are now *almost* on the same axis, but not quite; open controls subclassability outside module, but final controls it for both. Why not use access control modifiers, such as:
> 
> - public(open)
> - internal(open) (default)
> - fileprivate(open)
> - private(open) = final
> 
> Then, we could remove the "final" keyword from the language completely, and use access control as normal. I feel like this unifies everything much better (private(open) does seem a little weird though).
I think it does feel a little weird, and maybe makes things more complicated... for example, private(open) by itself doesn't tell me at a glance what consumers of the framework will see... maybe this because of the 'open' being there... it feels like just plain 'private' is better... then I can reason, 'oh this is only a private class, I'm the author so I can do what I want here' or 'oh, this ones public but not open'... maybe I'm wrong though.... 🙃

Thanks,

Andre

> On Jul 15, 2016, at 1:27 AM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:
> 
>>> On Jul 14, 2016, at 2:39 PM, Chris Lattner <clattner at apple.com> wrote:
>>> 
>>> asks the community for an in-depth discussion of the secondary points of the proposal: does it make sense to require every member to be marked as “overridable” in order to be overridden by an open subclass outside of the current module?
>> 
>> To be clear: You want this discussion to happen in the next review thread, rather than in this thread?
>> 
>> -- 
>> Brent Royal-Gordon
>> Architechies
>> 
>> _______________________________________________
>> 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/b9ff3527/attachment.html>