> On Jul 5, 2016, at 6:48 PM, Karl via swift-evolution
> wrote:
>> On 5 Jul 2016, at 08:49, Andre via swift-evolution
>> wrote:
>>
>> Personally, it's perhaps more of an "aesthetic" thing I suppose but I would
>> definitely prefer that my
> On 5 Jul 2016, at 08:49, Andre via swift-evolution
> wrote:
>
> Personally, it's perhaps more of an "aesthetic" thing I suppose but I would
> definitely prefer that my internal classes stay internal even if there is a
> public subclass... I don't like how that
Thanks for the link — imho it's really hard to keep an overview of this list…
So, I'll follow the leader ;-) and delay further posts on this topic
>> Not everything can be solved with protocols (stored properties, anyone?)
>
> Sure, it's not completely painless, but you can declare
>
>
> On Jul 5, 2016, at 12:03 PM, Tino Heth <2...@gmx.de> wrote:
>
>
>> How would this look in the exported API? Would it simply show itself as not
>> inheriting from anything? If your base class inherited from something (e.g.
>> NSObject), would the public subclasses show themselves as direct
> How would this look in the exported API? Would it simply show itself as not
> inheriting from anything? If your base class inherited from something (e.g.
> NSObject), would the public subclasses show themselves as direct subclasses
> of that superclass (NSObject)?
I wouldn't care, but the
> On 5 Jul 2016, at 08:01, Charlie Monroe via swift-evolution
> wrote:
>
> IMHO these things can be solved by private protocols with default
> implementation to reuse the code:
> Or you can just create a private class and use its instance in your classes:
The other
How would this look in the exported API? Would it simply show itself as not
inheriting from anything? If your base class inherited from something (e.g.
NSObject), would the public subclasses show themselves as direct subclasses of
that superclass (NSObject)?
IMHO these things can be solved by
Personally, it's perhaps more of an "aesthetic" thing I suppose but I would
definitely prefer that my internal classes stay internal even if there is a
public subclass... I don't like how that leaks my internal implementation like
that...
Though maybe the more swift thing to do would be to use
I'm running into "class cannot be declared public because its superclass is
internal" issues on a regular basis, and I wonder if it wouldn't make sense to
allow this combination:
It might be less useful as soon as there are abstract classes or generic
protocols, but even then I think I'd like