🚀 go-pugleaf

In article <3575@richsun.cpg.trs.reuter.com>  
jack@richsun.cpg.trs.reuter.com (Jack Gidding) writes:
> 
> When I include the header files from two different classes into a third 
> class, and each of the included classes have a single init: method 
> defined, I get messages similar to the following:
> 
> main2.m:18: warning: multiple declarations for method `init:'
> /Clib/RP.h:32: using `-init:(int )pSize'
> /Clib/RS.h:31: also found `-init:(OBJPTR )s'
> 
> Why is this happening??? Sometimes it tells me that it resolved which 
> init to use, sometimes not, and sometimes it resolves it to the wrong 
> init:.
> 
> So, why is it telling me that it is using one method or another...
> shouldn't this be left up until run-time? 

You ARE doing someting undesirable as far as the Obj-C runtime system is  
concerned. A selector name, like a C function, should only have one set of  
argument types. [Think about it: you wouldn't write two C functions with  
the same name, but different arguments, even if they were static to the  
module in which they appeared. Well, you might, but you couldn't get a job  
with my firm. 8^)]

You ARE allowed to EXTEND a method's arguments. For example, you can have

- init;
- init:sender;
- init:sender forSize:(int)aSize;

because the selector's complete name is everything that comes before the  
colons, plus the colons themselves. In my example, the selectors are  
"init", "init:", and "init:forSize:", as you will recognize if you have  
ever set a breakpoint on complex methods in gdb.

So the bottom line is that you should have more than one init name if you  
have different argument types. IMHO, that's preferred anyway. All through  
the appkit, "init" takes no arguments. I wouldn't mess with that  
assumption. Instead, the unadorned "init" chooses reasonable defaults and  
then passes control to the "designated initializer." All True NeXTSTEP  
Gods write classes this way. 8^) One last example:

- init
	{
	NXRect defaultRect = {{0.0, 0.0.}, {100.0, 150.0}};
	return [self initFrame:&defaultRect];
	}

- initFrame:(NXRect *)aRect   /* this is the "designated initializer" */
	{
	/* do some stuff here */
	return self;
	}

I agree, on the surface this can be a nuisance. I have come to like  
specific init names, because they are self-documenting.

--
Gregory H. Anderson          | "We're very tolerant around here,
Benevolent Dictator-for-Life |  being only amateurs ourselves."
Anderson Financial Systems   | - Tortoise (Godel, Escher, Bach)
greg@afs.com  (Nextmail OK)  |