[swift-evolution] [Proposal Draft] Remove open Access Modifier

Jean-Daniel mailing at xenonium.com
Wed Feb 22 01:15:38 CST 2017


> Le 21 févr. 2017 à 17:19, Tino Heth via swift-evolution <swift-evolution at swift.org> a écrit :
> 
> 
>> I’ll concede that the proposal makes a claim that might very well be disproved. I would very much like to see an actual example of a public class that **has** to be public but **shouldn’t** be open for obvious reasons. I would happily accept being shown wrong on that point.
> This is afaics one of the most active disputes on evolution — and you can save you a lot of grief by accepting that it is pointless:
> The whole discussion isn't based on facts at all, despite many false claims that marking things as final is generally better.
> I have asked for a single example to prove this in the past as well, so I guess no one can present such a thing to you.

This is bad faith. The original discussion contains many real life example. You just don’t want to admit open is useful for many library writers.

> It is personal preference, so arguments don't help much here.
> 
> Maybe it helps to know the whole story, as everything started with "final should be default", followed by a try to forbid subclassing for types from a different module by default, finally arriving at the current compromise where you have to decide wether module clients should be allowed to subclass or not.
> Nobody ever requested that public should be the only access level, so there has been only been pressure applied from one direction — it's interesting to see some backlash now.
> Imho people already were quite tired of discussion when public/open was accepted as a compromise...
> _______________________________________________
> 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/20170222/3c45a28c/attachment.html>


More information about the swift-evolution mailing list