Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!agate!shelby!polya!ali
From: ali@polya.Stanford.EDU (Ali T. Ozer)
Newsgroups: comp.sys.next
Subject: Re: Objective C compiler options
Message-ID: <11608@polya.Stanford.EDU>
Date: 31 Aug 89 14:52:55 GMT
References: <24042@labrea.Stanford.EDU>
Sender: Ali T. Ozer <ali@Polya.Stanford.EDU>
Reply-To: aozer@NeXT.com (Ali Ozer)
Organization: .
Lines: 29

In article <24042@labrea.Stanford.EDU> Dave Combs writes:
>In the StepStone manuals, there is a section showing and describing the
>C code that is generated by the Objective-C part of the compiler ...
> ... One is supposed to be able to get this by giving the -C
>option to the compiler.  However, the NeXT version of the GNU compiler
>uses the -C option for something completely different ...

The NeXT ObjC compiler is a ObjC in, assembly out compiler. Thus
no intermediate C code can be generated.

> ...  The new method for this class (Item) contains the statement
>  cell = [TextFieldCell newTextCell:""];
>
>On the first invocation of this Item "new" method, everything is fine.
>On the second, the "self" variable for the new Item is somehow
>used by TextFieldCell, because after the above statement, even though
>self has not changed, [self name] reports "TextFieldCell" as the class,
>and the data (dumped in gdb) is all set to look like a TextFieldCell.

Hmm. Trying to look at self through gdb can sometimes be confusing &
misleading; "print *someid" might not be correct, depending on the context.
Try using "print *self->isa" to see what class "self" is... If it does
seem like it is TextFieldClass, then try "make clean" and remake, just to
eliminate any problems that might arise from an inconsistency between 
the header files and classes. If the problem still exists, please post 
(or mail me) the class (or the +new method) and we can take a look at it.

Ali Ozer, NeXT Developer Support
aozer@NeXT.com