Nil Advice

Recently I wrote that one of the things I really like about Objective-C is how it handles nil-values when calling methods. It certainly makes for code that's easier to read however it does have a downside as mentioned by Daniel Jalkut of Red Sweater software. In Don't Coddle Your Code, Daniel writes:

It s also worth noting that LaMarche s defense of nil ing out instance variables hinges on the presumption that messaging nil is safe. True, messaging nil will not cause a crash. But is that safe? Not if it changes the behavior of your code in unpredictable ways.

He goes on to demonstrate his point with some contrived but applicable code:

if ([mDiplomat didReturnGestureOfPeace] == NO)
{
    [[NuclearWarehouse nuclearMissile] launch];
}

Daniel's point is this:

The biggest disservice you can do to your users is to allow them to run code that has unpredictable behavior. The whole point of programming is to make computers accomplish tasks in predictable ways.

I think he makes an excellent point. To paraphrase -- and I'm sure C++ developers will agree -- just because you can do something doesn't mean that you should. This language feature is a boon for those that understand how to use it effectively and design interfaces that work well with it.

Some Thoughts on Cocoa and Objective-C

I originally started writing this about a year and a half ago. It's been sitting on my desktop waiting to be published but for one reason or another I never got around to it. My thoughts now seem trite, but it's interesting to look back. One of these days I should write a post that covers the more interesting aspects of Objective-C's design; more than just what's covered here.

---

I've been dipping my toes in Cocoa again lately, and I'm really starting to enjoy it. I first played with Cocoa when I got my first Mac in 2004. I really thought there was something promising there but I couldn't wrap my head around how all the pieces fit together. After being abused by other OOP languages and their GUI frameworks Cocoa seemed really backwards. Delegation instead of subclassing. Freeze dried objects and connections that are brought back to life at runtime, etc. And the language. Why this bizarre language with it's odd syntax?

Each of the choices in isolation appear to be fairly arbitrary, or different for difference's sake. But as you learn more about the development model you can definitely see a method to their madness. The choice of language is a rather interesting one because it forms the foundation of how applications are written for the Mac. So why Objective-C? In order to understand why Cocoa, OS X's native framework is written in it it's important to know where OS X came from.

In the late 80s NeXT Computer was building high end computer workstations for education and businesses. The crown jewel of NeXT was its operating system: NextSTEP. NeXTStep was a performant, object-oriented, preemptively multitasking operating system with a graphical user interface. In order to quickly build the operating system and its application software a very performant, dynamic, reflective language was needed. At the time the best choice was probably a little-known superset of C called Objective-C.

In the early to mid 90s Apple was looking for a successor to its aging operating system. After several failed attempts to build one in-house Apple was approached by NeXT. NeXT convinced Apple that it had the technology that Apple needed. In the end NeXT Computer was bought by Apple, and NeXT Step was transformed into Mac OS X. If you've ever wondered why classes are prefixed with NS in Cocoa now you know why.

I've found Objective-C to be a really interesting and fairly elegant language. One of the more interesting things I found was that Objective-C uses a completely different calling metaphor from traditional OOP languages that I've learned. What most languages refer to as calling methods, Objective-C calls message sending. The distinction is more than skin deep, it's a fundamentally different paradigm. If you're experienced with the mainstream OOP languages you've spent a great deal of time thinking aboout class taxonomy and how classes relate to each other. You're trained to think that classes are types and methods are associated with the types. This makes a lot of sense if you look at the problem from a compiler's perspective. If you know the class and method at compile time then you can statically jump to the appropriate address. It's faster than a dynamic lookup but you pay for the boost in performance and the currency is developer time.

A message sending paradigm on the other hand is quite different. When you want an object to perform some operation you send a message to that object with some arguments. The object that receives the message will dispatch the appropriate method for the message. Typically there is a one-to-one mapping between messages and methods but in some cases you might want to respond to messages that don't correspond to a method.

You might boil the difference between method calls and message sending down to a difference in who is responsible for finding and invoking the appropriate code. In the method calling convention the caller is responsible (via the compiled code) for determining the address to jump to. Message sending on the other hand leaves the receiver of the messag to determine what method to invoke. Another interesting side effect of message sending is that sending a message to a non-existant object is perfectly legal whereas calling a method on a non-existant object is not. In Objective-C sending a message to nil returns nil. You can chain these together without any problems.

    return [[[a firstChild] nextSibling] nextSibling];

As I mentioned earlier, when an object receives a message that it doesn't understand it is allowed to perform any operation that it wants to.

Integrating Growl - A Quick Start Guide

As promised, here is a quick start guide to integrating Growl support into a Cocoa application. The documentation expects that you've worked with Xcode before and are familiar with creating new build phases and writing Objective-C code. For the impatient and those that just want to play around I've created a gist with the project. You'll probably want to clone the project instead of looking at it online because it contains some binaries..

git clone git://gist.github.com/297221.git gist-297221

The first thing you'll need to get started is a copy of Growl.framework. As of this writing the latest is version 1.2. Once you have a copy of the framework you'll need to link your application against it. To do so, simply drag and drop the framework onto the Linked Frameworks item in your Xcode project. Since the framework will need to be shipped along with your application you'll also need to ensure that it gets copied into your application's bundle. Create a new Copy Files build phase for your application's target, make sure that you set the Destination to Frameworks. Drag and drop Growl.framework from Linked Frameworks to the newly created build phase. At this point your application will compile against the framework and include it when building.

The next thing you'll need to do is create a plist file called Growl Registration Ticket.growlRegDict containing the registration information that will be required by the framework. Below is an example of such a file. You'll need to make sure that this file makes it into the application, this can be done by ensuring that its in the Copy Bundle Resources build phase.

In order for Growl to allow your application to send notifications you'll need to register the notifications that your application will be sending with the framework. To do this you'll need to create and implement a bare-bones delegate. All that's required is that you implement the (NSDictionary*) registrationDictionaryForGrowl method. The implementation of this method will simply need to return a dictionary whose contents come from the plist file created previously. The body of this method can be as simple as:

- (NSDictionary*) registrationDictionaryForGrowl {
   NSString* path = [[NSBundle mainBundle] pathForResource: @"Growl Registration Ticket" ofType: @"growlRegDict"];
   NSDictionary* dictionary = [NSDictionary dictionaryWithContentsOfFile: file];
  return dictionary;
}

Once this method is implemented, and an instance of the class is set as Growl's delegate by calling [GrowlApplicationBridge setGrowlDelegate: X] you'll be able to send messages to Growl using [GrowlApplicationBridge notifyWithTitle:description:notificationName:iconData:priority:isSticky]

That's about all there is to it. It's a fairly simple framework to integrate with, but the documentation neglects the fact that you have to implement (NSDictionary*) registrationDictionaryForGrowl

An example project exists as a gist on github.

git clone git://gist.github.com/297221.git gist-297221

Trials and Tribulations with Growl

A few nights ago I had just finished getting the core piece of a new application I started working on. It occurred to me that my little application and its users would benefit from having Growl support. It was pretty late, midnight or so and I didn't want to be up much later so I just downloaded the framework and had a quick skim of the developer documentation. It seemed pretty simple, but it was late and I knew that if I started that late I'd be up few a few more hours getting no where and end up going to bed feeling defeated. "Tomorrow, " I thought, "I'll do this tomorrow. If its as easy as the docs say then I'll have enough time to add at least 2 other features!".

I got up the next morning feeling great, I knew that come that evening I'd have integrated Growl support. Evening rolled around and I sat down and got to work. I re-read the documentation...well, skimmed is more acurate, and started following the instructions. I created the plist file containing the information that the documentation said I needed. I added a build step to copy the plist to my application's Resources directory. I double checked the name of the file -- the documentation says it's case-sensitive. I linked Growl.framework to my application. I added a build step to copy the framework to my application's Frameworks directory. And lastly I added the code from the documentation to send a notification to Growl ensuring, of course, I was sending one of the notification names that was in my plist file.

I clicked the Build and Run button, and my application compiled and my application's Dock icon started to bounce. By this point I felt like a kid at Christmas. I'd written my letter to Santa, stuffed it in an envelope, and very carefully, in my tidiest printing I wrote the address: "North Pole." I placed my stamp and tossed it in the mailbox. My letter must have gotten there, it hadn't been returned to sender so I knew that good stuff was heading my way.

The Dock icon stopped bouncing and my application's window opened up. "This is it, " I thought to myself "the moment of truth!" I clicked the button to fire off the notification aannnddd...nothing.

Silence.

"That's ok," I thought "it's probably some silly little thing I did wrong."

I looked at my run logs and they were eerily quiet. No messages at all. Surely if I'd done something wrong the framework would tell me. That must mean that the framework didn't get copied to my application's bundle. But if that's the case, then shouldn't there have been an error in the log about my code trying to perform a selector on a class that didn't exist? So that must mean that my code that posts the notification was never called. This sounds like a job for Captain Breakpoint!

I placed a breakpoint on the first line of my method and started the application again. Application startup under the debugger always takes longer so I was caught off guard when my application's window opened up. I moved my mouse cursor over the button, knowing that I was one mouse click away from finding out that my code wasn't being called thereby giving me all the information I'd need to fix the problem. My eyes narrowed as I pressed the button.

Half a second later I was staring at the Xcode debugger, my line with the breakpoint highlighted and a stack trace showing me that execution was indeed stopped in my method. I felt totally disarmed like I'd just gathered up my courage to tell that guy what I really thought of him only to be knocked off my feet by an overpowering wall of cheap cologne.

"What...the...what?"

I gingerly stepped through the method stopping just shy of executing the line to post the notification. Pausing for a second to think about what could possibly happen next. If the debugger tosses me out of my method, I know that either the framework doesn't exist or my parameters are causing it to barf. If the debugger stops and the next statement in this method...well that doesn't sound easy to debug, so lets hope that doesn't happen. I stepped over the line and found myself looking back that beautiful line of code just after the call into the framework.

This doesn't make sense. The framework accepted my parameters without problem, ostensibly did something with them and succeeded. So what could it possibly be? The framework didn't log anything, so it must not be a problem with my code. But no notification showed up, so the problem must be that Growl just isn't running. At that moment notification showed up in Growl -- but not from my application.

"Well, if other apps can send notifications then it's gotta be something I'm doing wrong." Since the documentation told me that all I needed to do was create a plist file and make sure it was in my application's Resources folder I figured I'd double check, and sure enough it was there. I'd just been banished to developer's purgatory where I have to debug configuration..

I thought to myself, "If my application has to have one of these plists, then other apps must have to have them too!" The first few applications I found didn't have one of those plists and they were working just fine. Finally I found an application that had a plist. So I compared them to make sure I'd done it right and sure enough I found a problem with my configuration. I updated my file, saved, built and ran the app again. My application's window popped up and I clicked the button and this time...nothing happened...again.

Silence.

Not believeing that it was something that I'd done I cleaned, rebuilt, and ran the application a few times knowing that it shouldn't make any difference in the world but hoping that it would just magically start working. After several runs in vain I figured that maybe The Google would have an answer for me. Sure enough, after trying a few google-y incantations I found some source code buried on a page that showed how to initialize Growl implementing a delegate method. I modified my code in a similar way, saved and ran again. I clicked the button and was surprised to see my little notification appear on the screen - only an hour after I started.

---

Truth be told, the Growl documentation did mention that one could would have to implement a delegate if you were attempting to talk to Growl 0.7, but since my code was running against 1.2 I didn't think I'd need to. In any case I managed to get it to work, but not without some frustrations that could have very easily been avoided had the Growl team produced some other artifacts that were as easy to find as the developer's documentation.

The first of these is some sort of a quick-start guide that just provides the bare minimum steps that are needed to use the framework. The developer's guide was littered with documentation about old versions. I don't need to know that stuff. Just assume that I have the latest and tell me exactly what I need to do.

Another thing that would have really helped, especially for developers that like to get dirty is a downloadable example. I'm sure they have one somewhere, but I wasn't linked to from their documentation so it effectively didn't exist.

Last lastly, but certainly not least is some level of logging in the framework itself. This would have been immensely helpful since I'd be able to tell if the framework was finding my plist or not, or whether there was a problem with my parameters. Don't just leave me to figure it out on my own, give me some help!

I hope what I'm saying doesn't label me an Open Source Douchebag. Honestly, I'm really just trying to improve the project by making it easier to get people up to speed. And in the next few days (hopefully) I'm planning on uploading some sample code along with a quick-start blog post.

On Subclassing

And now for another excursion into the depths of my experience and thinking about object oriented design and philosophy. This time I'm going to talk about some pitfalls I've seen with one of the most commonly used, and abused tools in the object oriented developer's toolbox: subclassing and access modifiers.

Subclassing has been around since the dawn of objected oriented programming. It's just one of many ways to enhance code reuse, but I've seen enough blood shed due to the misuse of this feature that I've stopped using it in cases where I can get away with another approach. The core of the problem with subclassing tends to be an eagerness to reuse as much code as possible without any consideration of how code reuse decisions will effect the overall design. Yes, reusing code means that there are fewer places to change when a change must be made, but subclassing is a merely a means to an end. There are other, better approaches that give the same benefits without the problems.

So what are some of the problems with subclassing? I think the central failing is that subclassing is the most tight form of coupling there is. When you decide to subclass an implementation, you've solidified part of your implementation. A common word of wisdom is that you should always code to interfaces so that implementations can be changed at a later date with a minimal of fuss. By subclassing an implementation you are publically declaring that you are and always will be a subclass of X.

Another problem with subclassing is that you cannot narrow the interface of the class to anything smaller than the subclasses interface, even if it doesn't make sense. A textbook example of this in Java is the java.util.Stack class. java.util.Stack extends java.util.Vector which in turn extends java.util.AbstractList which is an abstract implementation of java.util.List. The java.util.List interface contains methods such as add, get, indexOf, etc. If you've followed along that means that java.util.Stack, in addition to its own interface also has these methods. A stack should really only have two methods for mutating the stack (push and pop) and perhaps some methods to determine how many items are on the stack. By subclassing, java.util.Stack has guaranteed that it implements the java.util.List interface and therefore has methods that allow a developer to work around the stack encapsulation. Ah, but you can override those methods in the subclass with ones that do nothing or throw a java.lang.MethodNotImplemented exception. Certainly you could, but then if an instance of java.lang.Stack was passed to a method that accepted java.util.List it would not produce the desired result -- either by throwing an exception or not performing the operation.

No discussion of subclassing would be complete without mentioning the Liskov Substitution Principle. I think it's great advice it theory, but as we've all seen it's not exactly easy to follow. If the JDK developers can make such an error with all of their review process, how does a lowly developer stand a chance?

Aside from these problems there's always the minefield of access modifiers. In my opinion there should really only be 2 at the class level: public and private. Protected variables are a major cause of headaches since subclasses can easily muck around with the internals of a superclass, violating encapsulation. Protected methods provide a second interface to the class which has to be maintained and documented -- as if a single interface wasn't enough problems. So, private and public is really all that's needed - stuff that's internal and stuff that's public.

So if not subclassing then what? In a word delegates, specifically the delegation pattern. With the delegation pattern you simply implement interfaces, if applicable, and delegate parts of the implementation to a concrete class. By doing so you don't have to expose any information about how your class works internally. And since you're not subclassing you don't inherit interface that doesn't make sense for your class. As an added bonus, since you're using the public interface to the concrete class you don't have to worry about methods internal to the implementation changing or becoming deprecated.

Delegates are also an effective strategy for reusing code. You can encapsulate logic into a single class and use it from anywhere in your application. This is a great benefit when you have an irregular class heirarchy, it effectively gives you mixins without the headaches of trying to figure out which pieces of implementation are coming from which mixin.

Obviously there are times when subclassing is the right thing to do. But in my experience I see it used much more often than it should be and usually for the wrong reasons. I hope my thoughts have given you something to think about next time you reach for that subclassing hammer.

First Impressions of Cocoa

Over the past few months I've been doing a lot of playing around with development on the Mac using Cocoa. Although I do disagree with some of the design decisions that have been made, but for the most part I really like both Objective-C and Cocoa. The developer community is extremely vibrant and very helpful, a feeling I haven't had elsewhere.

One of the things I really like about Cocoa is that it handles a lot of the mundane tasks for you. There's a technology called CoreData that handles object graph persistence. You simply setup your data model and the framework takes care of the rest. This is really great since one initial hurdle I always run into when coding, and where I usually lose steam is in persisting and reading data that my application is working with, CoreData takes care of this beautifully.

Another great technology is Bindings which is built on top of Key-Value-Coding and Key-Value-Observing. In essence, Bindings allows you to visually tie the value of a control to a piece of data in your data model. This removes the need for reams of "glue" code that you'd otherwise have to write to keep your View and Model consistent. With these two technologies all you really have to do is write your Controllers.

Granted, the Controller is generally where the rubber meets the road, but since the frameworks take care of the Model and View you're free to think almost exclusively on the problems and structure of the Controller.

So far I've been really happy with the results that I've been able to achieve with only a small time investment. Between the results and how supportive the developer community is I think the Mac is a great platform to develop for and look forward to doing so in the future.

Exception in thread "main" java.lang.NullPointerException

I've learned over my years of programming in object oriented languages is that null values can be really painful. Due to poor decisions by API designers code has to be littered with null checks to ensure that values returned from API calls return something other than null. Failing to make these kind of checks while oftentimes harmless, can cause problems once you start testing code off of the happy-path.

There are few things a consumer of a poorly designed class can do other than simply read the documentation, add null checks and test thoroughly. So, if you're designing a new class it's really important that you get it right the first time. While I can't give much advice about the design of your specific class, I can give some hints nulls and when it's appropriate to use them.

These rules aren't hard and fast, there are times when these rules are completely wrong. But it's been my experience that these rules are applicable in almost all cases.

Return null when you mean null.

A common mistake that programmers make (myself included) is to simply default values to null. I attribute this to laziness. It's much easier to simply use null as a default value instead of some sensible value. Certainly there are times when null is a good choice, but I think as programmers we tend to fall into the trap of using null because its convenient.

The first thing to understand about null is that it means the absence of a value. It means there's nothing to see here, move on. It doesn't mean empty string, it doesn't mean 0, it doesn't mean empty instance of a class it means that there is nothing to refer to, no value. Unless your program needs to distinguish between an empty value and no value provided there is little need to use null.

Return an empty list or collection instead of null.

If you have a method that is supposed to return a list of something, you should always return a list regardless of whether there is anything to put in the list. Typically, when a caller asks for a list they are usually going to loop over its contents performing some operation. Since a loop over an empty collection is effectively a no-op returning an empty collection simplifies the calling code by removing the need to check for null.

Return a safe instance instead of null.

When possible, return a do-nothing instance of a class instead of null. This is really useful for classes that contain other objects that are used frequently. This allows callers chain method calls together without having to worry about null return values. Typically this is useful for classes that are treated as services.

An example of this might be an a getXPathEngine() method of a Document class. If there is no implementation of XPathEngine available, then Document.getXPathEngine() should return a safe implementation of XPathEngine instead of null that way callers don't have to constantly check for the presence of the engine, they can assume that it exists.

Tell Me Why!

Whenever I start trying to learn a new codebase, one of the first things I do is try to get an understanding of how the code works at a high level. Generally this isn't too hard, I just find out where the program starts, which is usually pretty obvious, and work through the code from there. But there's a problem I always run into the code only tells me what it does, it doesn't tell me the most important thing: why. Unfortunately, most projects don't maintain a good set of code-level documentation. Instead all documentation is locked away inside of heads of its developers as tribal knowledge.

So if documentation is needed where's the best place to keep it? In my opinion, the the documentation needs to be as close to the code as possible, so put your documentation in the code. The further away it is, the more likely it is that the documentation will get out of date, and the only thing worse than no documentation, is wrong documentation.

Now, what should be in those comments? Well, as I eluded to previously, it should tell me the why. If someone is reading through the code they surely have enough knowledge to be able to tell what's happening to which objects, so you can safely leave that out.