<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>Regarding the whole discussion about this topic, I think this decision is really a good one.<div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>Actually, even Swift source code use abstract classes.</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>Thanks to all for this really interesting discussion about this proposal.</div><div class=""><br class=""></div><div class=""><div class="">
<div class=""><div class="">--</div><div class="">David Scrève - DLTA Studio</div><div class="">Gérant - 06 27 69 58 14</div><div class=""><a href="mailto:david.screve@dlta-studio.com" class="">david.screve@dlta-studio.com</a></div></div>
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">Le 7 mars 2016 à 19:00, Joe Groff via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">The review of <span class="" style="font-family: 'Helvetica Neue';">SE-0026 "Abstract classes and methods"</span> ran from February 26...March 4, 2016. The proposal has been <b class="">deferred </b>from Swift 3. Discussion centered around whether abstract classes fit in the direction of Swift as a "protocol-oriented" language. Beyond any religious dogmas, Swift intends to be a *pragmatic* language that lets users get work done. The fact of the matter today is that one of Swift's primary target platforms is the inheritance-heavy Cocoa framework, and that Swift 2's protocols fall short of abstract classes in several respects, including:<div class=""><br class=""></div><div class="">- Protocols can require conforming types to provide properties, but extensions cannot instantiate storage into conforming types. Every conforming type must today satisfy a protocol's storage requirements itself.</div><div class="">- Type erasure is easier to accomplish using abstract base classes with generic subclasses. Protocol existentials today only support all-or-nothing type erasure, and don't support protocols with associated type or Self constraints at all.</div><div class="">- Protocols don't support language enforcement of separate implementor and user interfaces, since all of a protocol's requirements must be as visible as the conformance. An abstract base class can expose private or internal abstract requirements to its implementation subclasses while exporting a different interface for external users.</div><div class="">- Protocol extensions can provide default implementations, but there's no equivalent to 'super.' today for a concrete implementation to be able to chain up to a default implementation.</div><div class=""><br class=""></div><div class="">Unfortunately, the core team is currently bandwidth-constrained and can't immediately participate to the degree we'd like in the design of this important feature. Furthermore, "completing generics" is one of our primary goals for Swift 3, and proposals for addressing many of the above limitations with protocols are in various stages of discussion and design. We'd like to revisit this feature once the core goals of Swift 3 have been addressed, so we can more accurately consider its value in the context of a more complete generics implementation, and so we can address the finer points of its design.</div><div class=""><br class=""></div><div class="">Some things to consider for future revision:</div><div class=""><br class=""></div><div class=""><div style="box-sizing: border-box; margin-top: 0px; margin-bottom: 16px; color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);" class=""><br class="webkit-block-placeholder"></div><blockquote type="cite" class="">An abstract class cannot be instanciated. </blockquote><div class=""><br class="webkit-block-placeholder"></div></div><div class="">This can be prevented in cases when `AbstractClass(...)` is statically spelled, but the behavior of abstract class metatypes must be specified. Is `let classObject: AbstractClass.Type = AbstractClass.self` allowed? Does `let classObject = _typeByName("Module.AbstractClass")` work? If not, then the abstract class object cannot be used for metaprogramming or generic argument binding purposes. If it can be, then there's a static safety hole, since `classObject.init(requiredInitializer:)` would have to dynamically fail if `classObject` refers to an abstract class metatype.</div><div class=""><div style="box-sizing: border-box; margin-top: 0px; margin-bottom: 16px; color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);" class=""><br class="webkit-block-placeholder"></div><blockquote type="cite" class=""><p style="box-sizing: border-box; margin-top: 0px; margin-bottom: 16px; color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);" class="">When declaring an abstract property, you must specify which methods must be implemented : get, set, didSet, willSet. </p><p style="box-sizing: border-box; margin-top: 0px; margin-bottom: 16px; color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);" class="">If you do not specify anything, only setter and getter are made abstract as below : </p><div class="highlight highlight-source-swift" style="box-sizing: border-box; margin-bottom: 16px; color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);"><pre style="box-sizing: border-box; overflow: auto; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 14px; margin-top: 0px; margin-bottom: 0px; line-height: 1.45; padding: 16px; background-color: rgb(247, 247, 247); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; word-wrap: normal; word-break: normal;" class=""> abstract <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">var</span> url <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">:</span> <span class="pl-c1" style="box-sizing: border-box; color: rgb(0, 134, 179);">String</span></pre></div></blockquote></div><div class="">Only 'get' and 'set' are of interest for a property's interface. For consistency with protocol requirements, abstract properties should probably require an explicit '{ get }' or '{ get set }' declaration to indicate whether mutation is expected.</div><div class=""><br class=""></div><div class="">-Joe</div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></body></html>