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

[David Chisnall]

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.

> @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.

> 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...

> 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.

> What do you think?

Very nice in theory, but I'd like to know how we deal with the  
irritating corner-cases.

David