[cfe-dev] Proposal to simplify ObjC Type AST's

[steve naroff]

On May 24, 2009, at 7:10 PM, Chris Lattner wrote:

> On May 24, 2009, at 1:48 PM, steve naroff wrote:
>>>> I think having a common base class (abstract or not) makes either  
>>>> of these more appealing than what we have now.
>>>
>>> This composition enables the "protocol-qualified" concept to be  
>>> abstract too.
>>>
>>
>> Hey Chris,
>>
>> Sounds good to me. I'd simply call it ObjCQualifiedType (or  
>> ObjCProtocolQualifiedType).
>>
> I don't see that this adds any value, what problem does it solve?   
> Why add another set of multiple inheritance?

Just to simplify the discussion, let's put this suggestion on hold for  
now...I don't want it to distract from the more general discussion  
below.

> To me, we should have exactly one class for all of this.  The space  
> efficiency issue can be easily addressed by tail allocating the  
> array of protocol qualifiers (as a second step).
>

Based on your comments in Radar, I knew you preferred having one class  
for all this (which is why my first proposal had precisely one class).

After collecting feedback, I was convinced that designing a type  
hierarchy that modeled the language seemed cleaner (and was in the  
spirit of our existing AST's).

 From my perspective, it gives us the best of both worlds (and solves  
the fundamental problem of unifying all the ObjC types)...most clients  
will simply use ObjCObjectPointerType, however there are sub-classes  
if more detail is required.

> If there is a specific reason that lots of clients want to use  
> dyn_cast to determine if an interface pointer has protocol  
> qualifiers (instead of using ->getNumQualifiers() != 0), we can  
> definitely add helper classes for that.  I just don't think we  
> should make a big class hierarchy for no reason.
>

In terms of philosophy, I agree with you (less is typically more). In  
this instance, I don't agree the hierarchy is "big". There are 6  
classes which model the 6 ways you can specify an ObjC type (id,  
Interface *, Class, id <>, Interface <> *, Class <>) and 1 abstract  
class to unify them. This didn't seem gratuitous to me. From my  
perspective, hierarchies get big/complex when they introduce layers/ 
concepts that have little to do with the domain they are modeling.

My 2$,

snaroff

> -Chris