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

[steve naroff]

Hi David,

Some responses below...

On May 23, 2009, at 10:09 AM, David Chisnall wrote:

>
> On 20 May 2009, at 16:45, steve naroff wrote:
>
>>
>> On May 19, 2009, at 8:05 PM, David Chisnall wrote:
>>>
>>> On 20 May 2009, at 00:50, Fariborz Jahanian wrote:
>>>
>>>> I am not sure if any want want to do this. But following code is
>>>> legal:
>>>> #include <objc/objc.h>
>>>> id pi;
>>>> Class min()
>>>> {
>>>> return pi->isa;
>>>> }
>>>
>>> This is a much more common idiom.  Ideally, however, we would be
>>> treating this as an ivar access with a known offset of 0, rather  
>>> than
>>> as a structure field access.  This probably ought to generate the  
>>> same
>>> code irrespective of whether pi is an id, an NSObject* or an Object*
>>> (although it should give a warning / error on NSObject where isa is
>>> declared @protected).  Perhaps we should be declaring an implicit
>>> Class isa as an ivar on any ObjCIdType, so ObjCIdType defines a
>>> pointer to an object with a single ivar which accepts all messages.
>>>
>>
>> This sounds good to me.
>>
>> Consider the following pseudo code (for discussion...not meant to  
>> be complete):
>>
>> @class Class, Protocol;
>>
>> @interface id // ObjCIdType: The implicit root of all ObjC objects.
>> {
>>  Class isa;
>> }
>> // All ObjC roots will inherit the following class methods.
>> // This will greatly simplify defining an ObjC root class.
>
> Can you clarify what you mean by this?  Not all root classes  
> implement these methods (e.g. Object does not; it implements  
> equivalent ones with different names).  Are you proposing that we  
> synthesize these methods?  I'm not totally opposed to this, although  
> it will require a lot of runtime-specific code.

All I'm saying is we try and codify/standardize the root implied by  
the ObjC language (without adding any additional runtime  
requirements). For example, the ObjC language requires dynamic typing,  
implemented by having an 'isa' and methods to access the class/ 
metaclass objects synthesized by the compiler. From my perspective,  
the "core" methods should be standardized.

Since we didn't do this originally, we are (unfortunately) left with  
both NSObject and Object (with lots of conceptual overlap). As  
compiler writers, I'm not saying we are entirely responsible for  
defining this API (it would have to be done in collaboration with  
runtime/library folks). I've spoken with Apple's runtime lead and he  
is supportive of the general direction.

>
>
>> @interface Class // ObjCClassType: Will implicitly inherit from 'id'
>>
>> // No explicit ivar declarations, the structure of 'Class' is  
>> intentionally opaque (since the details are runtime specific).
>>
>> - (Class)class;
>> - (Class)superclass;
>> - (BOOL)instancesRespondToSelector:(SEL)aSelector;
>> - (BOOL)conformsToProtocol:(Protocol *)protocol;
>> - (IMP)instanceMethodForSelector:(SEL)aSelector;
>>
>> @end
>>
>> Conceptually, I like this...it makes some of the current legacy C  
>> 'magic' much more explicit.
>
> It's definitely a nicer model conceptually.
>

Glad you agree.

>> It does, however, require another bit of magic. Since the current  
>> definition of 'id' and 'Class' include a pointer, we will have to  
>> treat this specially (and not require an explicit '*' as we do for  
>> user-defined classes). Shouldn't be a big deal, however wanted to  
>> mention it.  One day, maybe we can make the '*' implicit for user- 
>> defined classes:-)
>
> Well, it would break almost all existing code, but definitely be  
> nicer syntax.  I'm not sure if there's a way of gradually  
> introducing it; even if you make it per-compilation-unit it's going  
> to be a bit confusing for people reading the code.
>
> If only we had a nice rewriter that could take Objective-C code and  
> emit slightly-modified code...
>

I could write the rewriter. Since types are unique, it's not entirely  
trivial (but I've dealt with this before in the ObjC->C rewriter).

>> The other issue is source compatibility with existing root classes  
>> (that explicitly declare an 'isa', for example). This could be  
>> handled in many ways...not worth talking about until we agree on  
>> the concept/direction.
>
> This is my biggest concern.  Ignoring the first ivar in a root class  
> if it's an id and is called isa is pretty trivial, but I wonder how  
> we will cope with existing Objective-C headers.
>
> The GNU headers, for example, have a silly definition of id, which  
> is (roughly):
>
> typedef struct objc_object { Class class_pointer; } *id;
>
> What happens with this model when someone does:
>
> id a = whatever;
> a->class_pointer = something;
>
> If we are treating id as an object with a public isa pointer, then  
> this code will break, and including the GNU header is likely to  
> cause conflicts too.

I'm not sure about this, but it's actually a good example of why this  
issue is worth tackling. This kind of source incompatibility between  
the Apple/GNU runtimes is kind of silly.

>
>
>> What do you think?
>
> Very nice in theory, but I'd like to know how we deal with the  
> irritating corner-cases.

I'll powwow with Chris and see what he thinks (he was out last week).  
 From my perspective, it's an example where it's hard to fully cleanup  
this level of the ObjC type system without addressing some of the  
issues outlined in this thread.

snaroff

>
>
> David