Evolution or De-Evolution?

When I started working with ActionScript, you could pretty much get away with anything. You had to screw up pretty bad to get a compiler error. If you got the thing to compile, you were golden. Your SWF might not do what you want it to do, but it would happily plug away doing its best. If it ran into something it couldn’t do, it shrugged its little virtual machine shoulders and moved on to the next thing. About the only thing you could do to take it down was an infinite loop. And when I say “infinite”, you know I mean “more than 15 seconds”.

Then we got ActionScript 2.0 and 3.0 and stuff like strict typing. If you said something was a Number, you had damn well put a Number in it. We were told this was a good thing. And it seemed to be. A lot of mistakes showed up right during compilation, and the compiler even showed you what line of code the error was on. So much easier than hunting them down in AS1. And as we moved on we got real classes and interfaces. If you said a class implemented an interface, it damn well better implement each and every method. And we were told this was good because it was a contract and made us better developers and made our programs more stable and scalable. And we got run time errors, which seem to almost always mean you are accessing some method or property on an object which turns out to be null. And we were told this was a good thing because unlike earlier ActionScript which would just fail silently calling methods on null objects, this let you know instantly something was wrong and exactly where the problem was. So we’ve gotten to a place where ActionScript looks an AWFUL lot like Java. And we all feel like we’ve really grown up over the years and become “real” programmers because we care about data types and interfaces and null objects.

Then we jump over to Objective-C and find that a good chunk of that stuff is out the window!

First, data typing. Say you want to hook up a method to get called when a user clicks a button. And say you make the button in Interface Builder and create an IBAction method to respond to the click. That method looks like this:

[c]- (IBAction)onClick:(id)sender;[/c]

Note the “id” in there. That’s the data type of the argument sent to the method, sender. In ActionScript event handler syntax, it’s the event’s target. In other words, the button itself. It’s real type is a UIButton pointer. So what is this “id” type? It is “the general type for any kind of object regardless of class.” Basically, Object, in ActionScript. Or even more accurately, the AS3 “*” data type, which can hold anything. You’ll find id’s all over the place, and wind up using them a lot. Apple also says, in the documentation:

If you are used to using strongly typed languages, you might think that the use of weakly typed variables would cause problems, but they actually provide tremendous flexibility and allow for much greater dynamism in Objective-C programs.

Wait a minute! All these years, I’ve been brainwashed into believing data typing is more important than oxygen, and now you’re telling me that NOT typing my objects allows for “tremendous flexibility” and “greater dynamism”??? I feel ripped off!

Well let’s see what else we have. Interfaces are really important. They form a contract and all that. Essential part of Object Oriented Programming. So let’s see. Objective-C has protocols, which are pretty much like interfaces. Probably one of the first you run into while doing iPhone dev is the UIAccelerometerDelegate protocol. There are three steps to accessing the accelerometer.

1. Implement the UIAccelerometerDelegate protocol.

[c]@interface MyClass : UIViewController {
…
}
@end[/c]

2. Set your class as a delegate for the acclerometer:

[c][[UIAccelerometer sharedAccelerometer] setDelegate:self];[/c]

3. Implement the accelerometer:didAccelerate method:

[c]- (void)accelerometer:(UIAccelerometer *)accelerometer didAccelerate:(UIAcceleration *)acceleration
{
…
}[/c]

The scary thing is that you can skip any one or even two of these steps and your app will still compile happily. In some cases it will even continue to function as expected!

Don’t believe me? Leave off step 1. Oddly enough, although this is the only one that will give you at least a warning, it will also result in your application running exactly as you expected it – you’ll get your accelerometer events right on schedule.

Leaving off step two isn’t surprising. You’re set up to be a delegate, but you never formally ask to be one, so no errors, no warnings, but no acceleration.

Leave off step 3. Surely this wouldn’t work! You’re saying this is a UIAccelerometerDelegate. You HAVE TO implement the key method of that protocol, right??? Nope. I’m afraid not. It will compile just fine. No errors, no warnings, no problem. Turns out that unlike interfaces in ActionScript (and most other languages as far as I know), protocols can have optional methods. What’s really odd is that accelerometer:didAccelerate is the ONLY method in the UIAccelerometerDelegate protocol, and it’s optional. What’s the point?

What this means is that if you happen to misspell “accelerometer” or “accelerate” (like I do at least 50% of the time – oh, and XCode doesn’t give you code hinting on protocol based methods either, so you do have to remember how it’s spelled), your code compiles and your app doesn’t do what you want, and you don’t have a clue why not. So, you can implement a protocol without saying you’re implementing it, and you can say you’re implementing it and then not implement it. I know there’s good reasons for all this stuff, but again, it’s just breaking down all those fixed ideas that have been drilled into my head over the last decade.

Next thing you know you’ll be telling me you can send a message to a null object in Objective-C and it won’t throw a run time error! hahaha!

Oh no, wait…