Official Forum for Programming in Objective-C (the iPhone Programming Language) - Stephen Kochan
May 21, 2018, 09:44:02 AM *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
   Home   Help Search Login Register Chat  
Pages: [1]   Go Down
Author Topic: 9.4 no errors or warnings when using add: method with id as receiver  (Read 8072 times)
Global Moderator
Full Member
Posts: 131

« on: November 22, 2012, 10:50:10 AM »

In question 9.4, I accidentally forgot to rename the add: methods. But the program compiles and runs without any warnings. Did I miss something? I would like to see what it looks like, if I ever use a method on a id receiver when that methodname is already taken.

As you can see in the code below, I tried a slightly different approach with Fraction instances and with Complex instances, to see if that made a difference. It doesn't, as all of this runs smoothly.

This is the relevant fragment from main.m (I reuse c1 en f1 from earlier in the program):
Code: (Objective-C)
id result, dataValue1, dataValue2;
//assign Fraction instances to the id type dataValue's
Fraction *f2 = [[Fraction alloc] init];
[f2 setTo:34 over:12];
dataValue1 = f1;
dataValue2 = f2;
result = [dataValue1 add:dataValue2];
[result print];

//assign Complex instances to the id type dataValue's
dataValue2 = [[Complex alloc] init];
[dataValue2 setReal:2 andImaginary:99.8];
dataValue1 = c1;
result = [dataValue1 add:dataValue2];
[result print];

Would anyone know why there is no complaint that the method add: is found in more than one class?

edit: only now I realise that maybe my XCode version has something to do with this. I use XCode 4.5.1 on OS X 10.7.5
« Last Edit: November 22, 2012, 11:53:00 AM by afterDark » Logged

I am just an amateur with Objective-C, don't let the moderator label fool you. Working my way through the book slowly.
Posts: 45

« Reply #1 on: October 23, 2013, 09:44:51 PM »

Maybe your Xcode version is higher than the one being used by the book and this was corrected.

Or your id type just knew exactly where to go. You still should change the method name to not receive unexpected errors, especially ones that will make you go crazy because you can't find anything wrong.

Full Member
Posts: 155

« Reply #2 on: September 09, 2016, 06:37:50 PM »

I too noticed the same thing--I didn't have to rename the add: method in order to avoid any warnings or errors.  Out of curiosity I found the NSObjectController.h file and looked to see if there was an add: method and I didn't see one.  So it could be the book is now out of date re: this issue.  Perhaps the add: method was removed from that class?  I have no idea, but if so, this conflict shouldn't exist anymore.

Keep in mind, that there is more to this issue than simply the same method name when the receiver is not known (an id variable).  There has to also be a mismatch in the return type and argument type as discussed in the book.  That's what also has to happen to get the error.  And as the book points out, if the return type and argument type are objects, then there is no problem (even if they are different objects).  The problems arise when there are basic data types involved (int, float, etc.) and those don't match.  Btw, I believe the issue about different objects not causing a problem was illustrated to us implicitly in one of the chapter's programs before it was explicitly explained.  I think we saw this with the Complex and Fraction class both returning and taking as arguments their own types, with the same method name, with an id object as a receiver and no problems occurred.  Again, if the argument types hadn't been these objects and instead basic data types (that perhaps were different from one another (e.g. int vs float), this example in the book would have caused errors.

I created a simple test file to test this and found the book was correct on this, and particularly the fine points of the mismatched return and argument types (basic data types) and method names with the same name.  This is the error message that you would have received if the book's warning was correct:

Error:  Multiple methods named 'add:' found with mismatched result, parameter type or attributes

This error would have to be corrected before you could compile the code.

One more bit of detail:  The above error would have appeared if you had ARC enabled (which is now the default).  If you had disabled ARC, the above error would have been only a warning and you would be allowed to compile.  Of course in both scenarios (with or without ARC) you would crash when running the code.  Here's the warning you'd get with ARC turned off:

Warning: Multiple methods named 'add:' found

If anyone else plays around with this and gets different results than me, I'd be interested in hearing about it.


Pages: [1]   Go Up
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.11 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!
Entire forum contents ゥ 2009 All rights reserved.