> On Feb 22, 2017, at 8:15 AM, Jean-Daniel via swift-evolution > <swift-evolution@swift.org> wrote: > > >> Le 21 févr. 2017 à 17:19, Tino Heth via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@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.
To me, the largest purpose is when you have a root class ("abstract") and a few subclasses that represent various options - in Scala, this would be a case class. For various reasons, it can't be an enum - for example, you need a lot of stored data and an enum case a(Int, Int, Int, Bool, Int, Double) is not very usable. In certain places, you can have switches based on the actual subtype - with the default case causing fatalError. In such case, you definitely don't want additional subclasses to exist outside of the module as it would break the assumption of a known number of subclasses. You can't make the root class final since you inherit from it. In such case, the public modifier makes sense. > > 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@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution