Inheritance

I was thinking about inheritance today and how much more I enjoy programming in ObjC where inheritance is used quite little compared to C++ where inheritance seems to be used quite often. Don't get me wrong, inheritance certainly has it's place in programming and I think it's a wonderful, wonderful thing. However, it seems to me that in C++ inheritance is used and only serves to make the programmer's job more tedious. In a lot of asynchronous programming, you have listener objects which get notified when a certain event happens. In order for the notifier to know how to notify an object, often a class is declared which one must inherit from and implement it's notification methods. As it turns out, there is a struggle between making the listener object know about many other objects (thus, decreasing encapsulation) and having the listener forward the notification to another object (perhaps a controller in a MVC app) that can do the appropriate thing with it. Since multiple inheritance in many workplaces is defined as EVIL (which it is), this can be a time consuming problem. The beauty of ObjC and the Cocoa framework is that more often than not you can set ANY object to be the listener of a notification. The notifying object can either require a protocol or check at run time whether the listener implements the method. This allows for the notifier to know about as little as possible and we can provide better encapsulation without "wasting" a simple forwarding message.

Iteration is Bad

Does it ever make sense to iterate through unordered collections? An unordered collection is precisely that, unordered, so what is the point of iterating through it? Iterating through adds complexity and bloat to code and limits expressiveness. It implies order where none exists. Yes, at some level, deep down in the machine, there must exist order, but exposing this to the programmer is pointless. Hopefully someday we'll have real live closures in ObjC, but until then, I'll be trying out some of the Higher Order Messaging frameworks that exist. Perhaps soon I'll write about why I think closures may have benefits over HOM.

The Counter

A new burger place just opened up near where I work called The Counter. It's totally awesome. That is all.

ACE up my sleeve?

I received very humorous email yesterday (although I'm not sure the sender found it funny) asking me about the build process for a cross-platform networking, communication, etc, library called ACE.

From the email:

"Something realy interested me in what you said. I understood you actually compiled ACE on a Mac Intel OS 10.4.6."

What's funny about this is that me and a coworker spent over a week of our lives trying to get this "cross-platform" library to compile on an Intel Mac. It was one of the most frustrating experiences of my life. One of the reasons being that ACE simply takes about 30 minutes to attempt a build on a 2 GHz Intel iMac.

This post is not an instructional post on how to get ACE to compile on an Intel Mac (although if you need help feel free to contact me, the ACE guys are quite unresponsive unless you fill their forms out exactly). Rather, it's a warning to consider your options carefully when deciding on using a cross-platform library. Now, I don't have much experience using ACE in code, although I do hear it's tricky to get it right. I simply speak from integrating such a thing into our Mac build.

It seems as though all the libraries we use that claim to be cross-platform have a deficiency on one play form or another and we often end up having to use #ifdefs in our code anyway (the very thing we're trying to avoid). The other thing that is very disappointing to me as a Mac developer is that the use of cross-platform libraries encourages a particular way of thinking in that we want to maximize code reuse, and thus we must target our code at the lowest common denominator. With all the rich technologies available to us on the Mac in Tiger and the amazing things coming in Leopard, it's really a shame that we can't take full advantage of them (I'm sure Windows and Linux have some great features unique to the platform, I just don't know what they are).

It's great to have a core platform that compiles on every OS under the sun, but at what point do we start to realize that the computing experience is different on different OSes? And that we should start coding differently and taking advantage of all that our respective environments have to offer.

Bonzo Project

Aaron Hillegass's most excellent idea of a central repository of reusable cocoa code. Check it out.

Mac Programmers Take Saturday Off?

Since this is a new blog, I decided to perform a little Technorati search to see if I showed up. Yeah yeah, I know I'm totally being sucked into this whole Silicon Valley culture. Next thing you know, I'll start thumbing through Valley Wag instead of the National Enquirer at the checkout line. But I digress. The point is, I was shamelessly searching for myelf on Technorati, when I came upon this helpful graph:



First off, I'd love to compliment Technorati for using a bar graph instead of the pervasive point connected line graph that is entirely misleading. I'm sure all my zero readers will hear me ranting about this later. Back to the graph, you'll notice a (disturbing?) cycle. Every Saturday there happens to be a sharp dip in the number of blogs containing Mac Programming. However, it stays fairly constant for the rest of the week. I was going to compare this to graphs of Windows, or C++ programmers and make some broad generalizations about how easy Mac development is or how much we love our work, or know how to lead balanced lives. Unfortunately for us all, the Technorati search is not performing properly right now. And, you know what? It's Saturday. I think I'll stop sitting in front of the computer and go do something fun. And you, diligent readers, should do the same.

Cross Platform GUI

http://www.losingfight.com/blog/2006/07/27/survey-of-cross-platform-gui-architectures/

Interesting post about cross platform gui development. As someone who is currently developing mac software, perhaps unsurprisingly, my thoughts are similar to Mr. Finnell's. I feel that in order to create the best user experience on each platform you develop for, the GUI must be done natively in order to take full advantage of all that the platform has to offer. Although it most likely increases total development time, the end result is a better product.

The Joys Of Threading

One of the wonderful things about Cocoa is that it performs so much of the heavy lifting for so many mundane tasks. This is great if you can do everything you want to from within the confines of Cocoa. Unfortunately, this is not always possible. Continuing on my Objective-C++ vector, I want to remind you that if you have C++ code that is doing anything interesting, spawning threads for example, you may need to do some of the heavy lifting yourself. As it turned out, I needed a NSRunLoop to exist in one of my C++ spawned threads. I only discovered this through some helpful hints on Apple Developer Mailing Lists. Although in my case it turned out to be a relatively easy fix (creating a NSRunLoop at the beginning of my C++ spawned thread), it's a good thing to keep in mind that when mixing languages, not all constructs are created equal.