<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On May 19, 2009, at 10:04 AM, steve naroff wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div>class <b>ObjCObjectPointerType</b> : public Type, public llvm::FoldingSetNode {</div><div><br></div><div> // We could used the lower order bits to encode id/Class (which are built-in, not user-defined).</div><div> // Alternatively, we could synthesize built-in ObjCInterfaceDecl's that correspond to id/Class.</div><div> ObjCInterfaceDecl *Decl;</div><div><br></div><div><div> // List of protocols, sorted on protocol name. No protocol is entered more than once.</div><div> llvm::SmallVector<ObjCProtocolDecl*, 8> Protocols;</div><div><br></div></div><div><div>public:</div><div> bool isObjCIdType();</div><div> bool isObjCInterfaceType();</div><div> bool isObjCQualifiedIdType();</div><div> bool isObjCQualifiedInterfaceType();</div><div> ...</div><div>};</div><div><br></div><div>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(<i>Interface</i>).</div><br class="Apple-interchange-newline"></div></span></blockquote></div><div><br></div>Hi Steve,<div><br><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>Ted</div></div></body></html>