<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 2:56 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; "><div><div>On May 19, 2009, at 11:22 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><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><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>//<span class="Apple-converted-space"> </span><b>Two classes</b>. In this case, ObjCObjectPointerType is concrete (and can represent id,<span class="Apple-converted-space"> </span><i>Interface</i>, and Class).</div><div><br></div><div>class<span class="Apple-converted-space"> </span><b>ObjCObjectPointerType</b><span class="Apple-converted-space"> </span>: public Type { ... };</div><div><br></div><div>// Represents "id <p>, Interface <p>, and Class<p>".</div><div>class<span class="Apple-converted-space"> </span><b>ObjCQualifiedObjectPointerType</b><span class="Apple-converted-space"> </span>: public ObjCObjectPointerType, public llvm::FoldingSetNode { ... };</div><div><br></div><div>//<span class="Apple-converted-space"> </span><b>Seven classes</b>. In this case, ObjCObjectPointerType is abstract. </div><div><br></div><div>class<span class="Apple-converted-space"> </span><b>ObjCObjectPointerType</b><span class="Apple-converted-space"> </span>: public Type { ... };</div><div><br></div><div>class<span class="Apple-converted-space"> </span><b>ObjCIdType</b><span class="Apple-converted-space"> </span>: public ObjCObjectPointerType { ... };</div><div>class<span class="Apple-converted-space"> </span><b>ObjCInterfacePointerType</b><span class="Apple-converted-space"> </span>: public ObjCObjectPointerType { ... };</div><div>class<span class="Apple-converted-space"> </span><b>ObjCClassType</b><span class="Apple-converted-space"> </span>: public ObjCObjectPointerType { ... };</div><div><br></div><div>class<span class="Apple-converted-space"> </span><b>ObjCQualifiedIdType</b><span class="Apple-converted-space"> </span>: public ObjCIdType, public llvm::FoldingSetNode { ... };</div><div><div>class<span class="Apple-converted-space"> </span><b>ObjCQualifiedInterfacePointerType</b><span class="Apple-converted-space"> </span>: public ObjCInterfacePointerType, public llvm::FoldingSetNode { ... };</div><div><div>class<span class="Apple-converted-space"> </span><b>ObjCQualifiedClassType</b><span class="Apple-converted-space"> </span>: 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></span></blockquote><div><br></div><div>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.</div><div><br></div><div>Are there cases in Sema that would be easier to write using the 7 class approach than the 2 class approach?</div><br></div></div></blockquote><div><br></div>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).</div><div><br></div><div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><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><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.).</div></span></blockquote><div><br></div><div><div>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.</div><div><br></div><div>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.</div></div><br></div></div></blockquote><div><br></div>I agree...didn't mean to dramatize:-)</div><div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><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> 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></span></blockquote><div><br></div><div>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.</div><br></div></div></blockquote><div><br></div>I agree, the cleaner solution is to have an explicit interface for both 'id' and 'Class'.</div><div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><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><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></span><br class="Apple-interchange-newline"></blockquote></div><br><div>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?</div></div></blockquote></div><br><div>Yep.</div><div><br></div><div>snaroff</div><div><br></div></body></html>