Should GNUObjCSourceParser extends GNUCSourceParser?

[GoogleCodeExporter]

There's quite a lot of duplication between the GNUObjCSourceParser and 
GNUCSourceParser. Do we 
need all this duplication? It used to subclass GNUCSourceParser (which meant 
that it inherited a lot 
from this).

Was this duplication done for a reason? If so, we should record the decision 
here. (There may well 
have been places that we couldn't override which makes it so).

Original issue reported on code.google.com by alex.ble...@gmail.com on 11 Jul 2009 at 11:12

[GoogleCodeExporter]

If I change the inheritance, I get two compile time errors. One is in the 
superclass constructor (which should be 
easy to deal with) and the second is:

    protected IObjCASTCompositeTypeSpecifier structOrUnionSpecifier() throws BacktrackException,

The return type is incompatible with GNUCSourceParser.structOrUnionSpecifier()

Original comment by alex.ble...@gmail.com on 11 Jul 2009 at 11:17

[GoogleCodeExporter]

Original comment by alex.ble...@gmail.com on 11 Jul 2009 at 11:17

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Other items - like unaryExpression - could probably be extended without 
duplication

    protected IASTExpression unaryExpression() throws EndOfFileException, BacktrackException {
        switch (LT(1)) {
        case IToken.tSTAR:
            return unarayExpression(IASTUnaryExpression.op_star);
        case IToken.tAMPER:
...
            case IObjCToken.t_AtThrow:
                return unarayExpression(IObjCASTUnaryExpression.op_AtThrow);
            case IObjCToken.t_AtSelector:
                return buildSelectorExpression();

could be done as:

switch(LT(1))
            case IObjCToken.t_AtThrow:
                return unarayExpression(IObjCASTUnaryExpression.op_AtThrow);
            case IObjCToken.t_AtSelector:
                return buildSelectorExpression();
default:
return super.unaryExpression;

Original comment by alex.ble...@gmail.com on 11 Jul 2009 at 11:47

[GoogleCodeExporter]

I've branched the objc.core to see if I can eliminate duplicate code as an 
experiment, but I've left trunk alone. 

Original comment by alex.ble...@gmail.com on 11 Jul 2009 at 1:20

[GoogleCodeExporter]

I've put the code into 

http://code.google.com/p/objectiveclipse/source/browse/#svn/test

I've broken something along the way, but I've replaced all the duplicate code 
with the C variants where 
possible. The DeclOptions for ObjC has 'protocol' stuff in it - do we need to 
know/care when a method is in a 
protocol or not? If not, we can probably prune further.

The declSpecifierSeq still has a bunch of code copied from the parent class. 

Original comment by alex.ble...@gmail.com on 11 Jul 2009 at 8:12

[GoogleCodeExporter]

Well initially that was my intention, but I ended up wanting access to alot of
private fields and to modify several private methods of GNUCSourceParser. Thats 
why I
did it the way I did.

Original comment by rrusaw@gmail.com on 12 Jul 2009 at 3:05

[GoogleCodeExporter]

I think we're going to need ObjC Linkage returned from quite a few of these 
ADTs as well, so probably copying 
is the right thing to do in any case.

Original comment by alex.ble...@gmail.com on 17 Jul 2009 at 8:40

• Changed state: WontFix