[swift-evolution] [Review] SE-0026 Abstract classes and methods

David Scrève david.screve at dlta-studio.com
Thu Mar 3 15:46:08 CST 2016

> It's the difference between forgetting to do two things and forgetting to do just one.
> Let's say I have a framework that requires me to supply a subclass of Foo to do something useful.
> With abstract classes, I just need to subclass Foo, and the compiler tells me what implementations I need to provide.
> With the protocol-based "solution" being proposed, I need to subclass Foo *and* I need to remember to declare conformance to FooProtocol. Then and only then can the compiler enforce anything.
> 2 != 1

	In addition, there is a different meaning between protocol and inheritance. When you inherit, you specialize a behavior with some piece of code. For example, consider UIView class. When you want to make a custom class, you inherit UIView and with a custom drawRect. This has no meaning to create a protocol to implement the drawRect because drawRect handle a behavior (specializing UIView) and not a delegate or datasource external interface (i.e protocol).

	* Protocol  is the right choice to provide external interface such as datasource, event handler, delegate. 
	* Extension is the right behavior for extension.
	* Inheritance is the right choice for specialization.

These 3 needs does not compete each other but are required for a multi-paradigme language that should handle severals kind of architecture designs.

That’s the reason I pull abstract class proposal because in our company we have the 3 kinds of architecture patterns.

That’s not easy to provide a simple and readable example for abstract classes, but there is actually a need. In some design, POP is a workaround for abstract classes. This works, but according to architecture design, it is a workaround.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4233 bytes
Desc: not available
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160303/f8db8291/attachment.p7s>

More information about the swift-evolution mailing list