🚀 go-pugleaf

Jack Gidding writes
> 
> Hmmmm..... this is really strange and very undesired behavior from  
Objective-C.
> 
> 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:.
> 
> 
> The code that has the init method is sililar in form to:
> 
> 	#import <RP.h>	// Both RP and RS have and init: method
> 	#import <RS.h>
> 
> 	id x;
> 
> 	x = [[RP alloc] init:(int) 5];
> 
> id is totally dynamic, and thus it really does not know which init to use....
> 
> So, why is it telling me that it is using one method or another...shouldn't  
> this be left up until run-time? 
> 
> 
> Am I doing something wrong to cause this?

Yeah, you're "type overloading" the method "init:".  Don't do that.
Make one of the "-initInt: (int) intVal" and the other one
 "-initObj: (OBJPTR) obj"

... or something like that.


> Thanks,
> 
> 
> Jack Gidding
> jack@richsun.cpg.trs.reuter.com
-- 
Jim Mackraz
jim@oceania.com

In article <3575@richsun.cpg.trs.reuter.com> jack@richsun.cpg.trs.reuter.com (Jack Gidding) writes:
>
>Hmmmm..... this is really strange and very undesired behavior from Objective-C.
>
>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'

This is just a warning to alert you that these are 2 different methods that
have the same name "- init:" but not the same parameter definition.  
C++ would have treated this as 2 really different member functions that
cannot override each other.  In Objective-C, you many have situations 
where you wouldn't know what is the exact kind of object that you're 
dealing with and then you wouldn't be sure what kind of parameter the
method -init: (which is may be implemented in many of your classes)
should take.
For example: you have an OrdCltn called "ordCltn" where you mix objects 
of classes RP and RS and you want to init: all it's members.
Since init: receives different parameter in RP and RS, you would
not be able to use the line:
[ordCltn elementsPerform: @selector(init:) with: yourValue];

Anyway, it's only a warnning.



    ____
     /  /   __ 
    /  /   /_/ /| /
 __/_ /__ / / / |/   o o o
 
                           Ilan Aisic
           Israel                                 USA
Voice:   972-4-344474                         1-914-644-7710
Fax:     972-4-342492                         1-914-644-7763
E-mail:  izeek@techunix.technion.ac.il        ilan@allink.com
-- 

    ____
     /  /   __ 
    /  /   /_/ /| /

In article <3575@richsun.cpg.trs.reuter.com> jack@richsun.cpg.trs.reuter.com  
(Jack Gidding) writes:
> 
> Hmmmm..... this is really strange and very undesired behavior from
> Objective-C.
> 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? 
> 

It's happening because the two init: methods are declared with different
argument *types*: one is an int and the other is an OBJPTR. This is a
Bad Thing. If you can statically type the object receiving the init:
message, the compiler can determine which one to use, and make sure
that a bad type conversion doesn't get applied. You don't want a bad
type conversion to get applied, because squishing a signed long int to
an unsigned char (for example) is likely to result in an error....

--
Nik Gervae
Software Publications, NeXT Computer, Inc.
ngervae@next.com
[[[[NXDisclaimer alloc] init] disclaim] free];

In article <3575@richsun.cpg.trs.reuter.com> jack@richsun.cpg.trs.reuter.com (Jack Gidding) writes:
>
>Hmmmm..... this is really strange and very undesired behavior from Objective-C
>
>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'

This is because you have init: defined differently in two places.  In
RP, you have init:(int)pSize while in RS you have init:(id)sender.
This is a nono.  If you need an initializer that takes an int for the
starting size, call it - initSize:(int)pSize, etc... and call that.
Don't forget to call [super init]...


andrew
-- 
andrew@cubetech.com     | "We shall not cease from exploration
Andrew Loewenstern      |  And the end of our exploring
Cube Technologies, Inc. |  Will be to arrive where we started
                        |  And know the place for the first time." -T.S. Eliot

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'

The problem is that the compiler doesn't know which init: to use.  It
must either know the type of the receiver or the two methods must have
identical types.

|
|
|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:.
|
|
|The code that has the init method is sililar in form to:
|
|	#import <RP.h>	// Both RP and RS have and init: method
|	#import <RS.h>
|
|	id x;
|
|	x = [[RP alloc] init:(int) 5];
|
|id is totally dynamic, and thus it really does not know which init to use....
|
|So, why is it telling me that it is using one method or another...shouldn't  
|this be left up until run-time? 

Yes, it should, but the compiler must generate code which is
equivalent to a function call.  To do this, it must know the types of
the arguments.  Since the types are different in this case, it doesn't
know what to generate.

|
|
|Am I doing something wrong to cause this?
|
|

Yes, you are.

|Thanks,
|
|
|Jack Gidding
|jack@richsun.cpg.trs.reuter.com

Ken

-- 
Kenneth Lerman                  ...!uunet!casey!gaboon!seltd!lerman
Systems Essentials Limited                            (203)426-4430
55 Main Street
Newtown, CT 06470

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

In article <1992Sep6.155059.13349@afs.com> greg@afs.com writes:> In artic
> 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^)]

actually having several functions share a single name can be very useful.
Its called overloading of course and exists in languages like Ada and C++.

As long as the compiler can resolve the reference to the correct call,
and you only overload semantically similar operations, it can be a great convenience.

There's no need to remember half a dozen names for the same conceptual operation.
you could then use just setValue: instead of setStringValue:, setIntValue:,
setFloatValue: etc - the compiler can figure out which one you meant from the
argument type and you can worry about other things.  Its convenient for some
of the same reasons that polymorphism is.

The AppKit would be a lot simpler to learn if Obj C allowed overloading IMHO.

of course it can be abused and lead to confusion - like most powerful features.

I once saw someone spend hours trying to figure out why he got a division by zero
error on a line that did not contain any division operators.  It turned out he
had redefined the operators to get a particular form of unit conversion (fine)
and had cut and pasted the division routine into the multiplication routine.



-- 
---------------------------------------------------
Alex Blakemore alex@cs.umd.edu   NeXT mail accepted

In article <60157@mimsy.umd.edu> alex@cs.umd.edu (Alex Blakemore) writes:
>In article <1992Sep6.155059.13349@afs.com> greg@afs.com writes:> In artic
>> 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^)]
>
>actually having several functions share a single name can be very useful.
>Its called overloading of course and exists in languages like Ada and C++.
>
>As long as the compiler can resolve the reference to the correct call,
>and you only overload semantically similar operations, it can be a great convenience.
 
  I agree that this can be convenient, but it is also a potential 
  source of problems.  In C++, overloading is almost mandatory to
  support initializers, but in other cases, it is generally only
  a cosmetic.

>There's no need to remember half a dozen names for the same conceptual operation.
>you could then use just setValue: instead of setStringValue:, setIntValue:,
>setFloatValue: etc - the compiler can figure out which one you meant from the
>argument type and you can worry about other things.  Its convenient for some
>of the same reasons that polymorphism is.
 
  I used to believe this too.  After thinking about it some more, I realized
  that the problem is NOT really with the issue of overloading, but with the
  fact that the base C datatypes are not first-class objects in Obj-C.  
  Thus I can easily create a single method called setObjectValue:(id)x
  which will take an anonymous object and do internally correct things
  to set the value based on x's class.  This is not possible with regular
  C datatypes, however, since they carry no object identification.  In
  Smalltalk, since all datatypes are classes and everything is an object,
  overloading is implicit since any object can be passed as any parameter
  to any method, as long as the method can deal with that type of object.
  C++ is a compile-time language where overloading makes some sense (and
  is sort of required).  Smalltalk is a run-time language where objects
  can (and should) be dynamically typed, not dealt with by a compiler.
  Obj-C sits on the fence, and while I much prefer it to C++, I still
  feel it has some shortcomings.  

>The AppKit would be a lot simpler to learn if Obj C allowed overloading IMHO.
>
>of course it can be abused and lead to confusion - like most powerful features.
>
>I once saw someone spend hours trying to figure out why he got a division by zero
>error on a line that did not contain any division operators.  It turned out he
>had redefined the operators to get a particular form of unit conversion (fine)
>and had cut and pasted the division routine into the multiplication routine.
 
  This is one of the problems with overloading.  
  It is, of course, also a problem with sloppy programming :-)

  Jon Rosen