<font face="tahoma,sans-serif">I agree, I think __attribute__ is the most appropriate way, as it can be made compatible with other compilers using macros, and is not changing the syntax of Objective-C.</font><div><font face="tahoma,sans-serif"><br>
</font></div><div><font face="tahoma,sans-serif">Perhaps I was premature in calling the feature "override", as I want the attribute to serve as an indicator that somewhere in the class hierarchy there should be a selector with the same signature, regardless of whether it is an optional from a protocol or from a superclass.</font></div>
<div><font face="tahoma,sans-serif"><br></font></div><div><font face="tahoma,sans-serif">That is:</font></div><div><font face="tahoma,sans-serif"><br></font></div><div><font face="tahoma,sans-serif">@interface MyBase</font></div>
<div><font face="tahoma,sans-serif">- (void)someMethodWithInt:(NSInteger)value;</font></div><div><font face="tahoma,sans-serif">@end</font></div><div><font face="tahoma,sans-serif"><br></font></div><div><font face="tahoma,sans-serif">@protocol MyProtocol</font></div>
<div><font face="tahoma,sans-serif">@optional</font></div><div><font face="tahoma,sans-serif">- (void)optionalMethod;</font></div><div><font face="tahoma,sans-serif">@end</font></div><div><font face="tahoma,sans-serif"><br>
</font></div><div><font face="tahoma,sans-serif">@interface MyDerived : MyBase<MyProtocol></font></div><div><font face="tahoma,sans-serif"><br></font></div><div><font face="tahoma,sans-serif">@end</font></div><div><font face="tahoma,sans-serif"><br>
</font></div><div><font face="tahoma,sans-serif">@implementation MyDerived</font></div><div><font face="tahoma,sans-serif"><br></font></div><div><font face="tahoma,sans-serif">- (void)someMethodWith<b><font class="Apple-style-span" color="#FF0000">i</font></b>nt:(NSInteger)value __attribute__((overrideOrImplement)) {</font></div>
<div><font face="tahoma,sans-serif">}</font></div><div><font face="tahoma,sans-serif"><br></font></div><div><font face="tahoma,sans-serif">- (void)optional<b><font class="Apple-style-span" color="#FF0000">m</font></b>ethod <meta charset="utf-8"> __attribute__((overrideOrImplement)) {<div style="font-family: arial; ">
<font face="tahoma,sans-serif">}</font></div><div style="font-family: arial; "><font face="tahoma,sans-serif"><br></font></div><div style="font-family: arial; "><font face="tahoma,sans-serif">@end</font></div><div style="font-family: arial; ">
<font face="tahoma,sans-serif"><br></font></div><div style="font-family: arial; "><font face="tahoma,sans-serif">I want the compiler to issue a warning for both methods, because they do not match an existing selector in the class hierarchy. It could even provide possible matches, similar to how Clang does searches for unknown types. </font></div>
<div style="font-family: arial; "><font face="tahoma,sans-serif"><br></font></div><div style="font-family: arial; "><font face="tahoma,sans-serif">I assume that adding a new attribute requires changing Clang, as I couldn't see how this could be added via a plugin.</font></div>
<div style="font-family: arial; "><font face="tahoma,sans-serif"><br></font></div><div style="font-family: arial; "><font face="tahoma,sans-serif">Thats much for all the discussion.</font></div><div style="font-family: arial; ">
<font face="tahoma,sans-serif"><br></font></div><div style="font-family: arial; "><font face="tahoma,sans-serif">Cheers,</font></div><div style="font-family: arial; "><font face="tahoma,sans-serif"><br></font></div><div>Stu</div>
<div><br></div></font><span style="font-family:arial, sans-serif;font-size:13px;border-collapse:collapse;color:rgb(80, 0, 80)"><strong><span style="color:rgb(153, 204, 255)">Stuart Carnie, CTO</span></strong><br><span style="color:rgb(255, 102, 0)"><strong><a href="http://manomio.com/" style="color:rgb(255, 102, 0)" target="_blank">manomio</a> | in retro we trust!</strong></span></span><br>
<br><br><div class="gmail_quote">On Mon, Nov 29, 2010 at 10:13 PM, Louis Gerbarg <span dir="ltr"><<a href="mailto:lgerbarg@gmail.com">lgerbarg@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
If you are only looking at this for a compile time warning (as opposed<br>
to new runtime hooks and altered code generation) then I don't think<br>
it is semantically similiar to the existing override attribute, and<br>
that would be a bad jumping off point. Also, if you want something<br>
purely for static analysis I don't think a whole extension to the<br>
language syntax is really appropriate. If I were proposing this, I<br>
would just add a new attribute, lets call it "implementsObjCProtocol"<br>
. You could then annotate declarations like this:<br>
<br>
- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView<br>
__attribute__((implementsObjCProtocol(UITableViewDataSource)));<br>
<br>
or even hide it behind a macro<br>
<br>
#define LG_IMPLEMENTS_PROTOCOL(x) __attribute__((implementsObjCProtocol(x)))<br>
<br>
- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView<br>
LG_IMPLEMENTS_PROTOCOL(UITableViewDataSource);<br>
<br>
You could then just store the attribute data hanging off the AST node,<br>
and in the static analyzer you could write a simple analysis pass that<br>
checks for all nodes that have the attribute and make sure the method<br>
part of the protocol they declare. This is basically how the current<br>
annotations in Foundation, like NS_REQUIRES_NIL_TERMINATION (though<br>
that is used during compilation for warning analysis not static<br>
analysis, but the concept is the same).<br>
<font color="#888888"><br>
Louis<br>
</font><div><div></div><div class="h5"><br>
On Mon, Nov 29, 2010 at 10:03 PM, Stuart Carnie <<a href="mailto:stuart.carnie@gmail.com">stuart.carnie@gmail.com</a>> wrote:<br>
> This is exactly what I am going for, simply to enhance compile-time and<br>
> static analysis, when the developer has identified they wished to override a<br>
> particular method.<br>
> I am definitely not looking to introduce method overloading or scoping as<br>
> that is far too intrusive.<br>
> Cheers,<br>
> Stu<br>
> Stuart Carnie, CTO<br>
> manomio | in retro we trust!<br>
><br>
><br>
> On Mon, Nov 29, 2010 at 6:27 PM, Alexei Svitkine <<a href="mailto:alexei.svitkine@gmail.com">alexei.svitkine@gmail.com</a>><br>
> wrote:<br>
>><br>
>> The benefit of an @Override annotation (for e.g. as implemented in Java)<br>
>> is for the compiler to warn you if you're not actually overriding something<br>
>> when you think you are. Which could happen if the superclass changed since<br>
>> the time you wrote the code or if you made a typo in the method<br>
>> name/signature.<br>
>> This is completely orthogonal to overloading. (Though I don't know<br>
>> Stuart's actual intention.)<br>
>> -Alexei<br>
>><br>
>><br>
>> On Mon, Nov 29, 2010 at 8:13 PM, Chris Lattner <<a href="mailto:clattner@apple.com">clattner@apple.com</a>> wrote:<br>
>>><br>
>>> On Nov 29, 2010, at 4:09 PM, Stuart Carnie wrote:<br>
>>><br>
>>> Hi all,<br>
>>> I would like to have a go at hacking a little on Clang when a get a bit<br>
>>> of spare time, and have found that adding support for override would be<br>
>>> useful little exercise. I've seen another post referring to Clang's support<br>
>>> for __attribute__((override)), and seems like I could use this as a starting<br>
>>> point.<br>
>>> Big Nerd Ranch would like to see an @override keyword, as follows:<br>
>>><br>
>>> @override<br>
>>> - (NSInteger)numberOfSectionsInTableview:(UITableView *)tv<br>
>>> { ... }<br>
>>><br>
>>> Hi Stuart,<br>
>>> Is your goal here to allow overloading of ObjC methods? If so, the<br>
>>> parsing isn't the hard part, you'd need to mangle selectors somehow, and<br>
>>> enhance the runtime to support this. This isn't something we want in ObjC,<br>
>>> because want to keep it simple.<br>
>>> -Chris<br>
>>><br>
>>> _______________________________________________<br>
>>> cfe-dev mailing list<br>
>>> <a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
>>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
>>><br>
>><br>
><br>
><br>
> _______________________________________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
><br>
><br>
</div></div></blockquote></div><br></div>