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

[Chris Lattner]

On May 25, 2009, at 10:40 AM, steve naroff wrote:
>> I don't see this.  I see this as two orthogonal axes: an "objc  
>> type" can either have a specified interface or be generic (id) on  
>> one axis.
>
> ...or it can be a generic class object (i.e. 'Class').

Ok, right.

>> On the other axis, it can have a variable number of protocol  
>> qualifiers (0 ... N).  Our current breakdown seems very odd to me,  
>> because there is little difference between the jump from 0 -> 1  
>> qualifier or from 1 -> 2, yet we model the jumps completely  
>> different.
>>
>> I really think that we should have one class.  If there are clients  
>> that are greatly simplified by being able to use dyn_cast to tell  
>> (e.g.) between id and NSString, then we can definitely add helper  
>> classes.  However, this is a syntactic issue, not a  
>> representational issue: the new classes should not have any  
>> contents.  Further, I really think we should add *at most* two new  
>> classes (one for "is an id thing" and "is an interface thing") not  
>> 6 or 7 or 8.
>>
>
> I agree it's not a representational issue. You clearly feel more  
> strongly about this than I do, so let's just go with one class...
>
> One question though...how is this issue different than how we  
> represent function types? Why don't we have 1 class (FunctionType)  
> instead of 3 (FunctionNoProtoType, FunctionProtoType)? Seems like  
> you could have methods on FunctionType that eliminates the need for  
> the sub-classes.

There are two differences: first, function type is "one dimentional",  
not two dimensional like objc types.  Second, there is a difference  
between a type with no prototype and a type with zero args.

We could definitely flatten the function types into one class, but  
because of the two reasons above, it is less of a clear win than with  
objc pointer types.  However, it is still probably a good thing to do.

-Chris