<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 7, 2016, at 1:18 PM, Gwendal Roué <<a href="mailto:gwendal.roue@gmail.com" class="">gwendal.roue@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">Le 7 janv. 2016 à 20:01, Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">The problem, though, is that abstract classes still have something that protocol do not, and this is the encapsulation of implementation details. Protocols, on the other side, are open in the wide, expose all their inner guts. The problem with convenience protocols that expose too much implementation details is that they make refactoring very difficult, if possible at all. Abstract classes don’t have this issue.</div></div></div></blockquote><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">That doesn’t have to be the case. In fact, if an enhancement came along that allowed protocols to have stored properties I think there will be a request to allow access control on those properties. If they aren’t required to have initial values some way to initialize them would also be necessary. This would allow pretty strong encapsulation.</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">You clearly address the hiding of implementation details from the code that uses types adopting such a protocol. But I’m not sure those implementation details can be hidden from the adopting types themselves?</div></div></div></div></blockquote><div><br class=""></div><div>Yes, it would be possible to have `private` stored properties in a protocol that were only visible within the file declaring the protocol. Presumably they would be used by default implementations or `final` methods added in an extension in the same file.</div><div><br class=""></div><div>I do not know whether Swift will go down the path of allowing this or not but it would be possible.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><br class=""></div><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">It is also possible that stored properties in protocols won’t be adopted or would be adopted without allowing for encapsulation. If that is the path that we follow then you make good points. I am just suggesting that we might want to wait and see before considering abstract classes. It might turn out that they really aren’t necessary.</div></div></div></blockquote></div><div class=""><br class=""></div><div class="">And we’ll continue fatalError("subclass must override") :-)</div></div></div></blockquote><div><br class=""></div><div>If we end up in that situation I would not be surprised to see a proposal for abstract classes. But I’d rather wait and see.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">Gwendal</div><div class=""><br class=""></div></div></div></blockquote></div><br class=""></body></html>