<div dir="ltr"><div>(I'm sorry i currently can't answer more recently)</div><div><br></div><div>2013/10/30 Ted Kremenek <span dir="ltr"><<a href="mailto:kremenek@apple.com" target="_blank">kremenek@apple.com</a>></span><br>
</div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word">
<br><div><div class="im"><div>On Oct 30, 2013, at 6:58 AM, variadictemplate . <<a href="mailto:variadic.template@googlemail.com" target="_blank">variadic.template@googlemail.com</a>> wrote:</div><br><blockquote type="cite">
<div dir="ltr">Thank you for all your comments.<div class="gmail_extra"><br></div><div class="gmail_extra">> <span style="font-family:arial,sans-serif;font-size:13px">(1) If a method is marked virtual in a class, should there be a warning to implement that method in the same class?</span></div>

<div class="gmail_extra"><font face="arial, sans-serif"><br></font></div><div class="gmail_extra"><font face="arial, sans-serif">In my eyes, that doesn't make sense. It would encourage the developer to implement the method within the base-class, which is what i want to avoid. That's why i disabled the warning warn_undef_method_impl in that case.</font></div>
</div></blockquote><div><br></div></div><div>Sorry, there was a missing word in my sentence (a typo).  I meant that if they did implement the method in the base class, then they would get a warning.  What I said was indeed contradictory.</div>
</div></div></blockquote><div><br></div><div>Oh, you're totally right, a warning would be necessary in that case.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><div class="im"><br><blockquote type="cite"><div dir="ltr">
<div class="gmail_extra"><br><span style="font-family:arial,sans-serif;font-size:13px">> (2) In a subclass, if a method is redeclared as being “non-virtual”, should we also guarantee that it is implemented in the @implementation?  That may be tricky of course with categories.</span></div>

<div class="gmail_extra"><font face="arial, sans-serif"><br></font></div><div class="gmail_extra"><font face="arial, sans-serif">What do you mean with "guarantee" - that there should be an error if the implementation can not be found? Then i would say no. I think, if it is redeclared in a subclass, it should be handled like a normal declaration, the attribute should have no more consequences for the further processing. In my current implementation, this is not the case, but i will fix that if the patch has a chance getting accepted.</font></div>
</div></blockquote><div><br></div></div><div>That seems reasonable.</div><div class="im"><br><blockquote type="cite"><div dir="ltr">
<div class="gmail_extra"><br></div><div class="gmail_extra">> <span style="font-family:arial,sans-serif;font-size:13px">I have also been in a situation where I have done the assert(false && "has to be implemented by subclasses") thing, but it is very rare. In Objective C subclassing is (compared to most OOP languages) infrequent and shallow. Since most the framework code in Cocoa/CocoaTouch/GNUStep chooses to use delegation as opposed subclassing it is generally possible to achieve the same sort of compile time warnings by having @required methods in a formal protocol on a delegate.</span></div>

<div class="gmail_extra"><br></div><div class="gmail_extra"><span style="font-family:arial,sans-serif;font-size:13px">I agree with you that it is a non-common construct, nevertheless there is a documented use case where such an attribute can be helpful (that is also the use-case i have in my companies app, i should have mentioned that in my first mail): class clusters (</span><font face="arial, sans-serif"><a href="https://developer.apple.com/library/ios/documentation/general/conceptual/CocoaEncyclopedia/ClassClusters/ClassClusters.html" target="_blank">https://developer.apple.com/library/ios/documentation/general/conceptual/CocoaEncyclopedia/ClassClusters/ClassClusters.html</a>). </font></div>

<div class="gmail_extra"><font face="arial, sans-serif">Class clusters may be realized with a delegate and @required-methods. But doing so would be a bit cumbersome in my eyes. The delegate is an implementation-detail of the abstract class and should not be public, so i have to put it into another header that the subclasses will import. Then, the methodnames of the abstract class and the protocol for the subclasses should not overlap, as i won't get anymore the warnings of unimplemented methods within the subclasses. Feels like a workaround, where a simple attribute would also do the work ;) But maybe i'm missing the point and there is a much more simpler and elegant way i have missed, than i would be glad to hear that!</font></div>

<div class="gmail_extra"><br></div><div class="gmail_extra">> <span style="font-family:arial,sans-serif;font-size:13px">It also seems like we should exclude this attribute to being applied to certain method families, such as “init”, as there are other idioms at play there.</span></div>

<div class="gmail_extra"><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div class="gmail_extra"><font face="arial, sans-serif">I haven't thought of that yet but yes, of course. I will add such behavior to my implementation if i have a list of method-families that should be excluded. </font></div>

<div class="gmail_extra"><font face="arial, sans-serif"><br></font></div><div class="gmail_extra"><div style="font-family:arial,sans-serif;font-size:13px">> Minor nit:</div><div style="font-family:arial,sans-serif;font-size:13px">

>  “classdeclaration”</div><div style="font-family:arial,sans-serif;font-size:13px">> For clarity (and to fix the typo), just say “class’s @interface"</div><div style="font-family:arial,sans-serif;font-size:13px">

<br></div><div style="font-family:arial,sans-serif;font-size:13px">OK :)</div><div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px"><div>> I have also been in a situation where I have done the assert(false && "has to be implemented by subclasses") thing, but it is very rare. In Objective C subclassing is (compared to most OOP languages) infrequent and shallow. Since most the framework code in Cocoa/CocoaTouch/GNUStep chooses to use delegation as opposed subclassing it is generally possible to achieve the same sort of compile time warnings by having @required methods in a formal protocol on a delegate.</div>

<div>> While I am generally in favor of adding annotations, I wonder if it is worthwhile to add an annotation for something that is really not a common idiomatic pattern in the language?</div><div><br></div><div>My reasoning about the class clusters also applies to this question.</div>

<div><br><span style="color:rgb(80,0,80)">> (2) In a subclass, if a method is redeclared as being “non-virtual”, should we also guarantee that it is implemented in the @implementation?  That may be tricky of course with categories.</span><br>

</div><div>>> I suspect you can get into similar situations today where the compiler does not have enough info to do things with @required in formal protocols and categories. I am sure you can if you are using class_addMethod to provide the IMPs at runtime. The language already provides @dynamic for dealing with that with respect to properties. Extending @dynamic to methods would work for the proposed annotation (if it makes sense to do the annotation at all) and solve the issue with formal protocols (though in practice I am not sure I have seen the cases ever come up, they are sort of pathological).<br>

</div><div><br></div><div>As said, i don't think that it is necessary to add logic that tries to "enforce" the implementation.</div><div><br></div><div><div>> Also, it seems like this could easily be modeled using protocols.  The subclass could implement a protocol with the required method, and use -Wprotocol to catch when something isn’t implemented.</div>

<div>> varadictemplate: Do you see a compelling need for this that cannot be modeled using protocols?  The class adopting the protocol is saying “all methods are implemented” for that protocol, which is natural way to express not only that a particular method is implemented, but that a group of methods are implemented.<br>

</div></div><div><br>My reasoning about the class clusters also applies to this question.<br></div><div><br></div><div>> My 2 cents (even if the feature does not end up in clang).</div>> The concept of "pure virtual" may be clear for people common from C++, but I dont think this is the right wording to choose for Objective-C.<br>

> The Apple documentation never ever mentions the term virtual once for objective-c.  I think the word commonly used is "abstract" so a better name for this attribute could be objc_abstract_method .</div><div style="font-family:arial,sans-serif;font-size:13px">

<br></div><div style="font-family:arial,sans-serif;font-size:13px">I have no personal preference for the name of the attribute, i am willing to change it to something the most of you feel good with ;)</div></div></div></blockquote>
<br></div></div><div>Another approach is in my reply to David Chisnall (later in this thread).  Instead of this being about specific methods, perhaps we can make this about protocols instead.</div><br></div></blockquote><div>
 </div><div>It sounds worth to consider. My first thought was: As proposed, the base class has to implement the protocol itself. Thus, it is no longer an "abstract class" and can be instantiated like any other one - that's a general semantic difference to the proposed attribute. I don't know if this is good or bad, maybe it fits more likely to the objective-c language than the attribute, but it is different to what i had in my mind. </div>
<div><br></div><div>Well, the more i think about it, the more i can warm up with that concept. Although i can't estimate all consequences of it. If you think that this concept would fit better into objective-c and should / could be implemented as an attribute, i would dig into it to create a patch for further discussions within the next week. If it should not be implemented as an attribute, i can't promise that I have enough time to dig deeper into clang to be able to implement it (but I would try to do so).</div>
</div></div></div>