> On Feb 22, 2017, at 8:15 AM, Jean-Daniel via swift-evolution
> <[email protected]> wrote:
>
>
>> Le 21 févr. 2017 à 17:19, Tino Heth via swift-evolution
>> <[email protected] <mailto:[email protected]>> 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
>> [email protected] <mailto:[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
