I'm nearing the end of a 3 week break. One more week to go. But I haven't been totally relaxing, I've been learning (again) Objective-C and Cocoa. First I started storyboarding CoffeeDate, the application I'm building. I removed all of the custom graphics which were distracting so I could concentrate on it's functionality. I had used some code to create a table view that I had pulled off the net for the purpose of demonstration in my presentation, but the code had a small part that was specific to the storyboard setup in the example that it was demonstrating, and quite different to mine so running it resulted in a crash. I couldn't penetrate the code even with the explanation in the tutorial and once the presentation was over I decided to relax and step back a bit. I took the offending code out and started reading an online book on Objective-C. I then moved onto  the next book from the same website on iPhone application development, following along the tutorials. I got half-way through hand decided I should be able to muddle along a bit further with my app. I did, but quickly got stuck and wound up reading a lot of Apple's iOS documentation. I've found the syntax of Objective-C a bit of an obstacle in learning, being more familiar with C++ syntax which every other language I've learnt tends to be closer to. Also the higher level concepts are difficult to follow. I find that material on Objective-C either deals with concepts on too much of a high level for me with loads of opaque jargon, or it goes right the other way dumbing down explanations with awful analogies. Where is the middle ground? I am quite willing to get right into advanced stuff. Just start with the background first. I almost wonder if it would be advantageous to write a "book" of my own on Objective-C, so I could explain the concepts to myself. Then when it was done I'd also have a rather good book that I could sell.

I'm currently zipping through a real book on Objective-C for beginners, trying to glean basic info that I may have missed. One utterly confusing thing was when it tried to explain the concept of Polymorphism and took an entirely different approach to the more standard explanations. I'm not sure how the different explanations marry up. This brings me to something else, I suspect that some of the names, terms and concepts sound really big but aren't quite that important to actually have their own name in practice. If they are, perhaps explain why it's so significant. Some history please. Lets use the example of Polymorphism which as I currently understand it is simply the ability for different classes to each contain a method that has exactly the same name. It's almost a Whoopy-doo in some ways. I mean, why the hell wouldn't you allow 2 or more entirely different classes to re-use a name? So for (real-life I did this once) example, if you were making Pong and you had a class called "Bat" and a class called "Ball" and a class called "Score" they could both have methods called update and update could work completely differently in each. Update in Bat and Ball might update the movement while update in Score will check the score and update accordingly. Well the explanation in this beginners book I think is basically saying that... well I don't know what it's saying. It literally says "..is the ability of an object of once class to appear and be used as an object of another class". Whaa? The example doesn't shed much light but thanks, I thought I knew what polymorphism was until I read that.

I just looked it up on Wikipedia and it appears that there are a few different definitions of Polymorphism but only one in the context of object-oriented programming. And it is essentially the same method name in different classes. Though now I'm not sure if it relates the the fact that the method could be from superclass. Ugh. Though that wouldn't make sense with my original explanation which I really think is the most accurate so far. So you can see why I'm confused. Most computer types just seem to like big words, perhaps over compensating in some way.

So why would Polymorphism be isolated as this grand feature when you'd kind of expect things to be that way anyway? Well I can think of 2 possible reasons: One reason is that being aware of this concept  means you'll use it in an advantageous way when designing code. If 2 methods in 2 different classes essentially do the same thing (though not entirely in their implementation) you will actually be inclined to name them appropriately. The other reason is that you couldn't always do this, so when you could, it became a feature.

So, a real programmer (or me one day in the future) may read this and cringe at the above.

Anyway, as you can see, learning iOS development is a bit of a struggle. Yet lots of people do it so I'll keep going.