[cfe-dev] Introducing attribute objc_pure_virtual_method

Wed Oct 30 06:58:18 PDT 2013

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.

> (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.

> 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 ;)

Hendrik

2013/10/30 Jean-Daniel Dupas <devlists at shadowlab.org>

>
> Le 30 oct. 2013 à 06:56, Ted Kremenek <kremenek at apple.com> a écrit :
>
> > On Oct 29, 2013, at 9:55 PM, Louis Gerbarg <lgerbarg at gmail.com> wrote:
> >
> >> On Tue, Oct 29, 2013 at 7:32 PM, Ted Kremenek <kremenek at apple.com>
> wrote:
> >> On Oct 29, 2013, at 3:16 PM, variadictemplate . <
> variadic.template at googlemail.com> wrote:
> >>
> >>> currently there is no possibility in objective-c to mark a method as
> "pure virtual" like in C++. I think the "pure-virtual"-construct enables an
> elegant and clean way to describe and specify APIs, although if it may be a
> rarely used construct.
> >>> A workaround for objective-c is to declare the method within the
> base-class and add to it's implementation an assertion like assert(false &&
> "has to be implemented by subclasses"). But i think it would be nicer when
> the compiler gives me a hint that there is something wrong, instead of
> crashing the app at runtime.
> >>>
> >>> So, with my attached patch I'm introducing an attribute for that case,
> named objc_pure_virtual_method. It can only be attached to methods of a
> class-declaration (the other way round: extensions, categories and
> protocols are excluded). If a subclass does not implement the method, it
> will cause a warning. If the subclass redeclares the method within it's
> @interface-declaration and also adds the objc_pure_virtual_method, no
> warning will be generated. If the call of an init-method to an instance of
> a class with pure virtual methods is detected, an error is generated.
> >>>
> >>> I'm not sure if the init-call to a subclass of an abstract class, that
> did not implement all pure virtual methods, should also produce an error,
> as this case already produces warnings of unimplemented methods - in my
> eyes, this is sufficient.
> >>>
> >>> Surely there are some issues with my current implementation, as i'm
> not so sure if i have chosen the right places to add the logic and about
> the names / warnings i have chosen and I'm happy to hear any suggestion /
> criticism.
> >>
> >>
> >> 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?
> >>
> >> (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).
> >>
> >> Louis
> >
> > Thanks Louis.  I was also thinking about this some more this evening and
> exchanged some thoughts with others, and I think I agree with you that this
> doesn’t seem worth adding to the language.
> >
> > 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 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 .
>
>
> -- Jean-Daniel
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20131030/5bc7908e/attachment.html>