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

[steve naroff]

On May 19, 2009, at 1:24 PM, Ted Kremenek wrote:

>
> On May 19, 2009, at 10:04 AM, steve naroff wrote:
>
>> class ObjCObjectPointerType : public Type, public  
>> llvm::FoldingSetNode {
>>
>>   // We could used the lower order bits to encode id/Class (which  
>> are built-in, not user-defined).
>>   // Alternatively, we could synthesize built-in  
>> ObjCInterfaceDecl's that correspond to id/Class.
>>   ObjCInterfaceDecl *Decl;
>>
>>   // List of protocols, sorted on protocol name. No protocol is  
>> entered more than once.
>>   llvm::SmallVector<ObjCProtocolDecl*, 8> Protocols;
>>
>> public:
>>   bool isObjCIdType();
>>   bool isObjCInterfaceType();
>>   bool isObjCQualifiedIdType();
>>   bool isObjCQualifiedInterfaceType();
>>   ...
>> };
>>
>> The following classes would be deprecated: ObjCQualifiedIdType,  
>> ObjCQualifiedInterfaceType. ObjCInterfaceType will still exist,  
>> however it's usage will be minimal (since you can't declare a  
>> variable/field of ObjCInterfaceType). You can, however specify an  
>> ObjCInterfaceType as an argument to @encode(Interface).
>>
>
>
> Hi Steve,
>
> 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?

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

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

snaroff


>
> Ted

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