Re: Release check

[David Ayers]

Adrian Robert wrote:

> 
> On Jun 2, 2005, at 11:52 AM, David Ayers wrote:
> 
>> Adrian Robert wrote:
>>
> 
> 
> This seems like a problem with gcc's support for alternative root
> objects.  Is there no way to tell the compiler to assume that id is
> NSObject instead of Object?  (Or do all root objects inherit from
> Object?  If this isn't a ridiculous question I can look into putting it
> in as an RFE for gcc I guess..)

Objective-C, the language, does not in anyway enforce a single root
object.  Even the OPENSTEP/Cocoa API uses multiple root objects (see
NSProxy and GDL2/EOF use EOFault as other examples of root class).  If
an object is untyped (i.e. id) gcc simply has no way of knowing to which
root object it may belong to.  One could in theory argue that this is
bug in the OPENSTEP/Cocoa API that it uses untyped objects as a common
return value of methods rather than NSObject *.  But my personal feeling
is that this is actually a feature.

> Also, it seems like a pain to need to include Protocol.h to ask an
> object if if conformsTo: @protocol(...), but this is the way NeXT did it
> so I guess we are stuck with that.  If I were redesigning this from
> scratch I would make sure all Objective-C language features were pulled
> in by one include -- if that.

NSObject declares:
- (BOOL) conformsToProtocol: (Protocol*)aProtocol;
and not
- (BOOL)conformsTo:(Protocol*)aProtocol;
which is declared by Object.

Eventhough Apple recommends #import <Cocoa.h> (or something similar)
realize that last time I checked there are still conflicting method
signatures within the Cocoa API which will always cause issues for
untyped receivers.  (IIRC setFont: was one but currently don't have
access to a Cocoa box to verify it.)

Cheers,
David