<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 1:24 PM, Ted Kremenek wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div 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></div></blockquote><div><br></div>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.</div><div><br></div><div>Here are two alternatives:</div><div><br></div><div>// <b>Two classes</b>. In this case, ObjCObjectPointerType is concrete (and can represent id, <i>Interface</i>, and Class).</div><div><br></div><div>class <b>ObjCObjectPointerType</b> : public Type { ... };</div><div><br></div><div>// Represents "id <p>, Interface <p>, and Class<p>".</div><div>class <b>ObjCQualifiedObjectPointerType</b> : public ObjCObjectPointerType, public llvm::FoldingSetNode { ... };</div><div><br></div><div>// <b>Seven classes</b>. In this case, ObjCObjectPointerType is abstract. </div><div><br></div><div>class <b>ObjCObjectPointerType</b> : public Type { ... };</div><div><br></div><div>class <b>ObjCIdType</b> : public ObjCObjectPointerType { ... };</div><div>class <b>ObjCInterfacePointerType</b> : public ObjCObjectPointerType { ... };</div><div>class <b>ObjCClassType</b> : public ObjCObjectPointerType { ... };</div><div><br></div><div>class <b>ObjCQualifiedIdType</b> : public ObjCIdType, public llvm::FoldingSetNode { ... };</div><div><div>class <b>ObjCQualifiedInterfacePointerType</b> : public ObjCInterfacePointerType, public llvm::FoldingSetNode { ... };</div><div><div>class <b>ObjCQualifiedClassType</b> : public ObjCClassType, public llvm::FoldingSetNode { ... };</div><div><br></div></div><div>I think having a common base class (abstract or not) makes either of these more appealing than what we have now.</div><div><br></div><div>Based on your feedback, it seems like you prefer having 7 classes that model the various ObjC types. True?</div><div><br></div><div>btw...the names are for illustrative purpose.</div><div><br></div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><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></div></blockquote><div><br></div>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).</div><div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><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></div></blockquote><div><br></div>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.</div><div><br></div><div>snaroff</div><div><br></div><div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div><br></div><div>Ted</div></div></div></blockquote></div><br></body></html>