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
>
> 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.
… but this single line only covers a single property in a single class, and you
have to implement willSet/didSet in every class if you depend on this behavior.
Protocols are nice, and if support for generics is added in the future, a whole
set of problems could be covered with those — but imho even protocols are no
silver bullet, and there are situations where they are not the right tool.
> IMHO if you need to hide the hierarchy *that* bad, it usually points to a bad
> design.
I don't believe in fighting developers with obscurity, so for me, it is not
about the hiding, but about clarity:
There is no clear way to express that a certain class shouldn't be used outside
its library without hiding all subclasses, too (well, you could write
documentation… but no one likes documentation ;-)
Best regards,
Tino
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
