> On Feb 22, 2017, at 1:41 AM, Charlie Monroe <[email protected]> wrote:
> 
>> 
>> On Feb 22, 2017, at 10:35 AM, Jonathan Hull <[email protected] 
>> <mailto:[email protected]>> wrote:
>> 
>>> 
>>> On Feb 21, 2017, at 11:29 PM, Charlie Monroe via swift-evolution 
>>> <[email protected] <mailto:[email protected]>> wrote:
>>> 
>>>> On Feb 22, 2017, at 8:15 AM, Jean-Daniel via swift-evolution 
>>>> <[email protected] <mailto:[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.
>> 
>> What I have done for this case is have a protocol with several private 
>> conforming Structs, and then wrap it all in a public final class which wraps 
>> a boxed instance of one of the conformers.
> 
> It's not always possible to flatten it down to structs, sometimes you do need 
> the class hierarchy and inheritance. ObjC support is one of the reasons, 
> others are purely based on the need for inheritance.

You could use a private abstract class and private classes instead of the 
protocol and structs respectively. Because they are classes, it shouldn’t even 
need the type erasure hack.  If we end up adding submodules, then it wouldn’t 
need to be in the same file.

Thanks,
Jon
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to