[cfe-dev] override support for Objective-C

[Louis Gerbarg]

If you are only looking at this for a compile time warning (as opposed
to new runtime hooks and altered code generation) then I don't think
it is semantically similiar to the existing override attribute, and
that would be a bad jumping off point. Also, if you want something
purely for static analysis I don't think a whole extension to the
language syntax is really appropriate. If I were proposing this, I
would just add a new attribute, lets call it "implementsObjCProtocol"
. You could then annotate declarations like this:

- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView
__attribute__((implementsObjCProtocol(UITableViewDataSource)));

or even hide it behind a macro

#define LG_IMPLEMENTS_PROTOCOL(x)  __attribute__((implementsObjCProtocol(x)))

- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView
LG_IMPLEMENTS_PROTOCOL(UITableViewDataSource);

You could then just store the attribute data hanging off the AST node,
and in the static analyzer you could write a simple analysis pass that
checks for all nodes that have the attribute and make sure the method
part of the protocol they declare. This is basically how the current
annotations in Foundation, like NS_REQUIRES_NIL_TERMINATION (though
that is used during compilation for warning analysis not static
analysis, but the concept is the same).

Louis

On Mon, Nov 29, 2010 at 10:03 PM, Stuart Carnie <stuart.carnie at gmail.com> wrote:
> This is exactly what I am going for, simply to enhance compile-time and
> static analysis, when the developer has identified they wished to override a
> particular method.
> I am definitely not looking to introduce method overloading or scoping as
> that is far too intrusive.
> Cheers,
> Stu
> Stuart Carnie, CTO
> manomio | in retro we trust!
>
>
> On Mon, Nov 29, 2010 at 6:27 PM, Alexei Svitkine <alexei.svitkine at gmail.com>
> wrote:
>>
>> The benefit of an @Override annotation (for e.g. as implemented in Java)
>> is for the compiler to warn you if you're not actually overriding something
>> when you think you are. Which could happen if the superclass changed since
>> the time you wrote the code or if you made a typo in the method
>> name/signature.
>> This is completely orthogonal to overloading. (Though I don't know
>> Stuart's actual intention.)
>> -Alexei
>>
>>
>> On Mon, Nov 29, 2010 at 8:13 PM, Chris Lattner <clattner at apple.com> wrote:
>>>
>>> On Nov 29, 2010, at 4:09 PM, Stuart Carnie wrote:
>>>
>>> Hi all,
>>> I would like to have a go at hacking a little on Clang when a get a bit
>>> of spare time, and have found that adding support for override would be
>>> useful little exercise.  I've seen another post referring to Clang's support
>>> for __attribute__((override)), and seems like I could use this as a starting
>>> point.
>>> Big Nerd Ranch would like to see an @override keyword, as follows:
>>>
>>> @override
>>> - (NSInteger)numberOfSectionsInTableview:(UITableView *)tv
>>> { ... }
>>>
>>> Hi Stuart,
>>> Is your  goal here to allow overloading of ObjC methods?  If so, the
>>> parsing isn't the hard part, you'd need to mangle selectors somehow, and
>>> enhance the runtime to support this.  This isn't something we want in ObjC,
>>> because want to keep it simple.
>>> -Chris
>>>
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>>
>>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>