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

[Ted Kremenek]

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?

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

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

>
>> 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20090519/72bc2281/attachment.html>