[cfe-dev] Proposal to simplify ObjC Type AST's
steve naroff
snaroff at apple.com
Tue May 19 12:06:35 PDT 2009
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>
More information about the cfe-dev
mailing list