Re: [swift-evolution] Public classes with private superclass

2016-07-05 Thread John McCall via swift-evolution
> 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

Re: [swift-evolution] Public classes with private superclass

2016-07-05 Thread Karl via swift-evolution
> 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

Re: [swift-evolution] Public classes with private superclass

2016-07-05 Thread Tino Heth via swift-evolution
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 > >

Re: [swift-evolution] Public classes with private superclass

2016-07-05 Thread Charlie Monroe via swift-evolution
> 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

Re: [swift-evolution] Public classes with private superclass

2016-07-05 Thread Tino Heth via swift-evolution
> 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

Re: [swift-evolution] Public classes with private superclass

2016-07-05 Thread Haravikk via swift-evolution
> 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

Re: [swift-evolution] Public classes with private superclass

2016-07-05 Thread Charlie Monroe via swift-evolution
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

Re: [swift-evolution] Public classes with private superclass

2016-07-05 Thread Andre via swift-evolution
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

[swift-evolution] Public classes with private superclass

2016-07-04 Thread Tino Heth via swift-evolution
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