> 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 ;-)
> 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?)
> 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.
Do you see a problem with "internal init"?
> Anyway, this is definitely out of scope of Swift 3 and as has been pointed
> out several times in the past month here, all discussions here should now
> focus on Swift 3 features.
Sorry, I've been busy with other things lately…
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?
Best regards,
Tino
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
