tags:

views:

141

answers:

5

Before I get flamed out for not checking previous questions, I have read most of the tutorials, and have Hillegass' book, as well as O'Reilly's book on it. I'm not asking for tips on Cocoa or what IDE to use.

Where my issue lies - my 'mental muscle memory' is making it hard for me to read Objective-C code.

I have no problems at all reading Java and C code and understanding what's going on.

Maybe I'm getting to old to learn a new syntax, but it's a struggle shifting mental gears and looking at Objective-C code and just "getting it" (I thought it might be an isolated case, but I have other friends who are seasoned devs who have said the same thing).

Are there any tricks that any non-Objective-C programmers who now know Objective-C used to help process the syntactical differences when learning it?

For some reason, I get dyslexic when reading Objective-C code. Maybe I'm not meant to be able to learn it (and that's ok too). I was hoping/wondering if there might be others who have had the same experience.

Edit:

Thought I should clarify the question a little more - where I have been struggling the most is in the message passing paradigm of Objective-C. As Jeremy Wall's answer alludes to, I think I need to find some mental tricks to help me convert my method call thinking to help me think of it as more of a conversational structure. Any other suggestions on how I can change the way I think are welcome.

+7  A: 

The thing that really made the light bulb go off for me in objective-c was realizing that rather than calling methods on objects your were designing a conversation between objects. Method calls are more like talking to an objective-c object. for instance.

[someObject doSomeThingTo:thisThing with:thisOtherThing];

is meant to be read like a conversation transcript. Literally you are telling someObject to: doSomeThing to thisThing with thisOtherThing. It's not so much a method as it is a sentence. A message which is really what the object model of objective-c is build around. Message passing between objects.

Jeremy Wall
This is an interesting way of looking at it. Being so conditioned to .method(param, param, ad infinitum), it's the message passing that's been the primary source of frustration. I think I'll try your trick.
Braintapper
It’s strange that you’re having problems with messaging, of all the differences. I find the named parametrs a great win as opposed to calling `foo.bar(x,y,z)`.
zoul
foo.bar(x,y,z) makes SO MUCH sense to me. Funny eh?
Braintapper
It's funny the things we can get hung up on isn't it.
Jeremy Wall
+1  A: 

Read a lot of good quality sample code; Apple's samples aren't particularly good - Aaron's code examples are much better. There are a few recent books with better code in them.

If you know C/C++/Java that you don't really understand a dynamic OO environment, so work on that - which is what the two previous answers here are really saying.

You need to really understand MVC to appreciate Cocoa.

The language isn't important - it's the patterns used in Foundation and UIKit that really matter.

Paul Lynch
I understand where you're coming from. MVC isn't really where my problem lies. I think Jeremy's answer is on the right track. My challenge has really been more centered around the message passing paradigm.
Braintapper
+1 for patterns/idioms.
zoul
Patterns are evil, I was hesitating about using the word. I like idioms much better, thanks.
Paul Lynch
+3  A: 

Objective-C probably feels significantly different than Java and C because it descends from Smalltalk. Smalltalk is an alternative (to Simula-influenced languages like Java and C) approach to OOP which introduced many of the concepts that appear in Objective-C.

I haven't found too many great books on Objective-C, but there are many fantastic books about Smalltalk. Since many of the concepts in Objective-C we're introduced in Smalltalk, I've found that Smalltalk books have better explanations of concepts like messaging and categories (and OO programming in general). Studying Smalltalk has improved my thinking and comprehension in Objective-C significantly. If you're willing to study a different language in order to learn to think in Objective-C (as bizarre as that sounds), I'd recommend Smalltalk, Objects, and Design.

dbarker
That's a great suggestion. I think I'll take a look at some Smalltalk materials.
Braintapper
+3  A: 

Here are a couple of simple things that may help. The first is, try breaking methods with multiple arguments across multiple lines. When you do this, Xcode will by default automatically align the colons preceding each argument. For example, you could rewrite the following expression

[NSMutableString stringWithContentsOfFile:@"/tmp/MyString.txt" encoding:NSUTF8StringEncoding error:NULL]

like this:

[NSMutableString stringWithContentsOfFile:@"/tmp/MyString.txt"
                                 encoding:NSUTF8StringEncoding
                                    error:NULL]

The thing on the left side is the receiver, the object or class we're sending the message to. The stuff on the right is the message. Note that the method name begins with stringWith.... That tells us two things. One, because it's a noun rather than a verb, we can assume that the primary purpose of this method is to return a value rather than to perform an action. Two, because it begins with the word string, we can assume that the value it returns is a string, in this case an instance of NSString. So it's a string created with whatever follows.

The rest of the method name, **...ContentsOfFile:encoding:error: describes each of the arguments, and includes a colon to delimit each name component from its corresponding argument value. So if we focus on just that portion of the expression

ContentsOfFile:@"/tmp/MyString.txt"
      encoding:NSUTF8StringEncoding
         error:NULL

we end up with something that looks like name-value pairs. Similarly, the following expression

[myString replaceOccurrencesOfString:@"foo" withString:@"bar" options:NSCaseInsensitiveSearch range:NSMakeRange(0, [myString length])]

may seem a lot more readable if rewritten like this:

[myString replaceOccurrencesOfString:@"foo"
                          withString:@"bar"
                             options:NSCaseInsensitiveSearch
                               range:NSMakeRange(0, [myString length])]

Note that the initial part of the method name is a verb, implying that the method's primary purpose is to perform some action rather than to return a value.

jlehr
This is really useful. Once I start coding, I'll definitely be following this advice.
Braintapper
+1  A: 

Honestly?

You just need to write lots of code.

I had similar problems at first, but then one day I just found I had got it.

JeremyP