<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=""><div class="">I see, that seems about right. If we have a bas class that is not dumb, and especially if that base class needs to call abstract methods in its existing methods, I don’t think that solution would be enough.</div><div class=""><br class=""></div><div class="">I would still rather have a solution that extends protocols than one that relies specifically on classes, it seems to me that doing so would make the resulting functionality more generic (for instance, it might be possible to use it with structs as well as classes). However, I’m starting to agree that this is an important language feature indeed, since I can’t think of any better (or even equivalent) way of solving the example you showed.</div><div class=""><br class=""></div><div class="">In any case, I think the current proposal might be a bit too complex. Having to specify which property accessors are abstract (get, set, willSet or didSet), for instance, is going too far IMO. In its current form I do not support it (so -1 for me), but I could get behind the same idea using a simpler design.</div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 26, 2016, at 2:20 PM, Vanderlei Martinelli <<a href="mailto:vmartinelli@alecrim.com" class="">vmartinelli@alecrim.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Thank you. This is a good suggestion, but does not fit the case. The `<span style="font-family:'Helvetica Neue';font-size:13px" class="">AccountAuthorizationControlle</span><span style="font-family:'Helvetica Neue';font-size:13px" class="">r` is an "abstract" class but it is not a "dumb" class. It store data, reference to injected class instances and do other important things. If I implement all of this as protocols I have to duplicate code here and there. I know I can use protocol extensions to provide default implementations. Even so, I'll have duplicate code.</span><div class=""><span style="font-family:'Helvetica Neue';font-size:13px" class=""><br class=""></span></div><div class=""><font face="Helvetica Neue" class="">Do not take me wrong, I really like protocols and structs and I understand how to use them, but it seems that many of us believe that the is something wrong with classes and the protocol/struct is the new Holy Grail. I disagree. New possibilites and new way to do things are always welcome, mainly if they are solid and consistent and really solves the problem intended to be solved.</font></div><div class=""><font face="Helvetica Neue" class=""><br class=""></font></div><div class=""><font face="Helvetica Neue" class="">I also understand that the Swift team does not want to introduce any new keywords to the language. </font>To tell the truth I think I need to read again all the information on Swift. I thought the Swift would be one thing, but looks like it will be another. It is likely that the wrong one is me.</div><div class=""><br class=""></div><div class="">Provide ways to create abstract classes and abstract methods is not a "keystroke saver". It is one of many concepts involved in OOP, IMHO.</div><div class=""><br class=""></div><div class="">-Van</div><div class=""><br class=""></div><div class=""><font face="Helvetica Neue" class=""><br class=""></font></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Fri, Feb 26, 2016 at 3:45 PM, Vinicius Vendramini <span dir="ltr" class=""><<a href="mailto:vinivendra@gmail.com" target="_blank" class="">vinivendra@gmail.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">It seems like having a protocol restricted to instances of ‘<font face="Helvetica Neue" class="">AccountAuthorizationController’ (as Brent suggested) would solve your problem, wouldn’t it?</font></div><div class=""><font face="Helvetica Neue" class=""><br class=""></font></div><div class=""><font face="Helvetica Neue" class="">You could just add all method declarations that are supposed to be abstract to that protocol instead, and then make sure your subclasses implement the protocol - which means the compiler forces them to implement the abstract methods.</font></div><span class=""><div class=""><br class=""></div>
> Currently I have in a private framework a class named `AccountAuthorizationController` with subclasses like `OAuthAccountAuthorizationController`, `OAuth2AccountAuthorizationController` and `WebFormAccountAuthorizationController` and so on.<br class="">> <br class="">> In the root "abstract" class I have methods without implementation where I have to use `fatalError()` to ensure that they will never been called. I cannot prevent the framework user to instantiate the `AccountAuthorizationController`, however.<br class="">> <br class="">> Look that this is only one example. I have other cases as well when I'd like to have abstract classes and abstract methods.<br class="">> <br class=""></span>> I know that structs and protocols are "elegant, simple and powerful" (as they seem to be all new frameworks and languages that pop up every day on the Internet) and the argumentsin favor of composition rather than inheritance. But I still would like to take advantage of the decades of available knowledge in object orientation in my projects.<span class=""><br class="">> <br class="">> +1 for abstract classes and abstract methods.<br class="">> <br class="">> -Van<br class="">> <br class=""></span><span class="">> On Fri, Feb 26, 2016 at 12:46 PM, Evan Maloney via swift-evolution<<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>(<a href="mailto:swift-evolution@swift.org" target="_blank" class="">mailto:swift-evolution@swift.org</a>)>wrote:<br class="">> > >Well not exactly, if you want the same behaviors in subclasses of UIViewController and UITableViewController :<br class="">> > >- with protocols + extensions, you write in once and apply it to each of your subclasses<br class="">> > >- with abstract classes you have to write 2 abstract classes, one for direct UIViewController subclasses, one for UITableViewController subclasses<br class="">> > <br class="">> > That's a problem with class hierarchies in general, not with abstract classes.<br class="">> > <br class="">> > You can use the same argument to call for the removal of classes from Swift, which is why I think the fundamental question is, are classes intended to be first-class citizens in Swift?<br class="">> > _______________________________________________<br class="">> > swift-evolution mailing list<br class=""></span>> > <a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>(<a href="mailto:swift-evolution@swift.org" target="_blank" class="">mailto:swift-evolution@swift.org</a>)<br class="">> > <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">> <br class="">> <br class="">><span class=""> </span>
</div></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></body></html>