[swift-evolution] Public classes with private superclass

[Charlie Monroe]

> On Jul 5, 2016, at 12:03 PM, Tino Heth <2th at 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 subclasses of that superclass (NSObject)?
> I wouldn't care, but the last option sounds sensible (although I hope I'll never have to directly subclass NSObject in the future ;-)

NSObject was just an example, of course, you can base it on NSView, etc.

>> IMHO these things can be solved by private protocols with default implementation to reuse the code:
> Not everything can be solved with protocols (stored properties, anyone?)

Sure, it's not completely painless, but you can declare

internal protocol MyClassProtocol {
	var foo: Bar { get set }
}

public class MyClass: MyClassProtocol {
	public var foo: Bar
}

It's 1 extra line of code. You declare the contract on stored properties by the protocol and just declare them on the class.

>> Or you can just create a private class and use its instance in your classes:
>> 
>> internal class MyClassImplementation {
>> 	/// Implement shared code
>> }
>> 
>> public class MyClass {
>> 	private var _impl = MyClassImplementation()
>> }
>> Which is fairly common solution.
> Those six lines are written easily, but they don't do anything, so you have to add tons of boilerplate to do forwarding — and you destroy the internal class hierarchy.

Yes, but I see a ton of various advantages such as breaking the code into various classes dealing with a particular problem. It seems to me like if you really need to hide the hierarchy, you should look into class clusters - such as NSString, where you declare a public abstract API and return internal subclasses using factory methods (yes, it is the exact opposite of what you want, but depending on your exact problem, it may get solved by this).

IMHO if you need to hide the hierarchy *that* bad, it usually points to a bad design.

> I know that anything that breaks compatibility with existing source has top priority now, and that there most likely won't be any resources to integrate stuff that doesn't fulfill that criterion — but has there been an actual announcement that no discussions about purely additive changes should be started at all?

Yes. See http://article.gmane.org/gmane.comp.lang.swift.evolution/21198

> Similarly, general discussions on this mailing list about blue sky additions to the language are distracting from our important goals, and the core  team generally isn’t paying attention to these anyway.  I would really appreciate it if we could stay focused on what is important, until the time is right to look beyond Swift 3.  This time is in August [...]




> 
> Best regards,
> Tino