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

[steve naroff]

On May 19, 2009, at 2:56 PM, Ted Kremenek wrote:

> On May 19, 2009, at 11:22 AM, steve naroff wrote:
>
>>> I personally like the idea of keeping these classes around and  
>>> having them subclass ObjCObjectPointerType.  This allows one to  
>>> use cast<> when querying for a specific Objective-C object  
>>> reference.  This allows clients that care about the differences  
>>> between these references to access this information using static  
>>> typing.
>>>
>>
>> We can certainly have more classes, however the original classes  
>> don't fit well with having one class that represents both id's,  
>> Interface's, and (when the time comes) Class.
>>
>> Here are two alternatives:
>>
>> // Two classes. In this case, ObjCObjectPointerType is concrete  
>> (and can represent id, Interface, and Class).
>>
>> class ObjCObjectPointerType : public Type { ... };
>>
>> // Represents "id <p>, Interface <p>, and Class<p>".
>> class ObjCQualifiedObjectPointerType : public  
>> ObjCObjectPointerType, public llvm::FoldingSetNode { ... };
>>
>> // Seven classes. In this case, ObjCObjectPointerType is abstract.
>>
>> class ObjCObjectPointerType : public Type { ... };
>>
>> class ObjCIdType : public ObjCObjectPointerType { ... };
>> class ObjCInterfacePointerType : public ObjCObjectPointerType  
>> { ... };
>> class ObjCClassType : public ObjCObjectPointerType { ... };
>>
>> class ObjCQualifiedIdType : public ObjCIdType, public  
>> llvm::FoldingSetNode { ... };
>> class ObjCQualifiedInterfacePointerType : public  
>> ObjCInterfacePointerType, public llvm::FoldingSetNode { ... };
>> class ObjCQualifiedClassType : public ObjCClassType, public  
>> llvm::FoldingSetNode { ... };
>>
>> I think having a common base class (abstract or not) makes either  
>> of these more appealing than what we have now.
>>
>> Based on your feedback, it seems like you prefer having 7 classes  
>> that model the various ObjC types. True?
>
> Interesting.  The 7 class approach is nice in that it clearly  
> represents the different categories of Objective-C object reference  
> types.  It also seems like a lot of classes, but it is conceptually  
> clean.  Most of the time clients would just use  
> ObjCObjectPointerType, fewer clients would use  
> ObjCQualifiedInterfacePointerType, and fewer would use the rest of  
> the classes.
>
> Are there cases in Sema that would be easier to write using the 7  
> class approach than the 2 class approach?
>

I'll have to look. I'm warming up to the 7 classes we've sketched. The  
common base gives us the simplicity we are shooting for (without  
putting too much into one class, which may have been too simplistic).

>>
>> btw...the names are for illustrative purpose.
>>
>>> It also seems to me that specific object references may need  
>>> information that isn't necessary for the others, (e.g., having the  
>>> 'Protocols' field).  Collapsing all object references into a  
>>> single class that contains the information for all of them seems  
>>> somewhat retrograde to me and a little inefficient.  We also don't  
>>> know what new kind of object reference types may come down the  
>>> line in future revisions of the language, so keeping the  
>>> modularity (with a common ancestor class) seems cleaner to me.
>>>
>>
>> Since we unique types, the space efficiency didn't concern me.  
>> Nevertheless, I understand your point on modularity. Consider this  
>> though...at the moment, we have one class that represents all the  
>> built-in C types. By analogy, we could have decided to have many  
>> subclasses (e.g. BuiltinCharType, BuiltinIntType, BuiltinFloatType,  
>> BuiltinBoolType, etc.).
>
> True, but the built-in types for C are bounded by the language  
> standard.  The Objective-C class hierarchy is defined by frameworks  
> and headers.  The latter seems a couple orders of magnitude larger.
>
> Also, the built-in types aren't really parametric, like id<...> and  
> Class<...>, which represent a family of types rather than a specific  
> type.  I also don't consider 7 classes to be a boatload of classes.
>

I agree...didn't mean to dramatize:-)

>> Instead of having a boatload of classes, we have a boatload of  
>> predicates on Type. That said, I think having is/getAs hooks on  
>> Type is an effective way to reduce the complexity of the class  
>> hierarchy (especially when the differences don't matter in many  
>> places).
>
> It's also conceptually muddy to me to throw all the bits that any  
> object pointer type would want to use into a single class.  It can  
> create cases where the meaning of different instance variables  
> becomes conflated depending on the kind of object pointer type one  
> is trying to represent.
>

I agree, the cleaner solution is to have an explicit interface for  
both 'id' and 'Class'.

>>
>>> One thing that isn't clear in this proposal is how the implicit  
>>> typedef definition for 'id' will work.  Will 'id x' resolve to a  
>>> declaration for 'x' that has an ObjCObjectPointerType?  What is  
>>> the type of 'id' when we aren't compiling for Objective-C?  (i.e.,  
>>> is it a pointer to a struct, as it is right now).
>>
>> Good question. The current scheme of modeling 'id' as a typedef was  
>> largely done to unify it with how C code works (i.e. the lowest  
>> common denominator). This isn't necessary though. In the new  
>> proposal, 'id x' will resolve to an ObjCObjectPointerType (as you  
>> suggest). The type of 'id' when compiling for C code will be a  
>> typedef (whose definition is in <objc.h>). The  
>> ObjCObjectPointerType would abstract you from understanding the  
>> details of the 'id' typedef.
>>
>
> Right.  So in the case of -x objective-c, the frontend will just  
> have to magically handle the typedef definition for 'id' if it  
> encounters it?

Yep.

snaroff

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20090519/f9c4d4d4/attachment.html>