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

[Chris Lattner]

On May 25, 2009, at 7:29 AM, steve naroff wrote:
>> 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.

Sounds fine to me.

>> 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.

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.   
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.

>> 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.

What clients would use this stuff?  Why can't they use  
getNumProtoQuals() or getInterface() != 0 etc?

This set of classes is complex because you're getting N*M classes  
(with an admittedly small value of M and N).

-Chris