[cfe-dev] Introducing attribute objc_pure_virtual_method

Thu Oct 31 16:00:09 PDT 2013

(I'm sorry i currently can't answer more recently)

2013/10/30 Ted Kremenek <kremenek at apple.com>

>
> On Oct 30, 2013, at 6:58 AM, variadictemplate . <
> variadic.template at googlemail.com> wrote:
>
> Thank you for all your comments.
>
> > (1) If a method is marked virtual in a class, should there be a warning
> to implement that method in the same class?
>
> 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.
>
>
> 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.
>

Oh, you're totally right, a warning would be necessary in that case.

>
>
> > (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.
>
> 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.
>
>
> That seems reasonable.
>
>
> > 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.
>
> 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 (
> https://developer.apple.com/library/ios/documentation/general/conceptual/CocoaEncyclopedia/ClassClusters/ClassClusters.html
> ).
> 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!
>
> > 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.
>
> 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.
>
> > Minor nit:
> >  “classdeclaration”
> > For clarity (and to fix the typo), just say “class’s @interface"
>
> OK :)
>
> > 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.
> > 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?
>
> My reasoning about the class clusters also applies to this question.
>
> > (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.
> >> 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).
>
> As said, i don't think that it is necessary to add logic that tries to
> "enforce" the implementation.
>
> > 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.
> > 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.
>
> My reasoning about the class clusters also applies to this question.
>
> > My 2 cents (even if the feature does not end up in clang).
> > 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.
> > 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 .
>
> 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 ;)
>
>
> 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.
>
>
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.

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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20131101/dae29516/attachment.html>