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

[steve naroff]

On May 25, 2009, at 12:52 PM, Chris Lattner wrote:

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

...or it can be a generic class object (i.e. 'Class').

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

Curious,

snaroff

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