Cocoa Is My Girlfriend

I was not born an Objective-C developer. I know that in some circles that is considered a mortal sin. Before learning Objective-C and Cocoa I had developed in a great number of languages dating back to the early 1980’s. I tell you this so that what you are about to read next is taken in the light that it was intended.

Take a look at the following lines of code:

- (void)doSomethingSpecial
{
	myVar.itsAttribute = 10;
	myOtherVar.itsAttribute = 20;
}

Now tell me, what is myVar and myOtherVar. Is it an object or a struct? Can’t tell from that piece of code can you. That is half of my argument against dot syntax in Objective-C. It makes the meaning of your code unclear. Objective-C is known for its self documenting nature. Dot Syntax removes that.

Next, lets take a look at another piece of example code:

-(BOOL)myCompliatedMethod
{
	MyObject *object = [[MyObject alloc] init];
	object.attribute1 = 10;
	object.attribute2 = 20;
	OtherObject *nextObject = [[OtherObject alloc] init];
	[nextObject doSomethingAmazingWith:object];
	if (nextObject.result > 10) {
		[object doSomethingElse];
		return NO;
	}
	return YES;
}

Yes, this is clearly contrived code. However, hopefully, its meaning is clear. dot syntax breaks up the flow of the code. Code should be elegant. It should be graceful and beautiful to look at. This is ugly, nasty code that you want to fold as fast as possible so that you can stop looking at it. The message passing lines are completely at odds with the dot syntax lines. The difference is striking and distracting.

When we write code, we care about its formatting. We care that the code is properly indented and that the indentation is consistent. We should care equally as much about its consistency of style and design. Switching from message passing over to dot syntax and back is not consistent.

Now lets compare this against keeping the entire method within message passing:

-(BOOL)myCompliatedMethod
{
	MyObject *object = [[MyObject alloc] init];
	[object setAttribute1:10];
	[object setAttribute2:20];
	OtherObject *nextObject = [[OtherObject alloc] init];
	[nextObject doSomethingAmazingWith:object];
	if ([nextObject result] > 10) {
		[object doSomethingElse];
		return NO;
	}
	return YES;
}

There is now a consistency of form and style. The code flows more smoothly and is not as jarring.

Dispelling some myths

I want to dispel a couple of myths about dot syntax in Objective-C while I am on the subject.

1. Dot syntax is not faster than message passing. It is syntactic sugar that is translated to normal message passing.
2. Using dot syntax to set an attribute to nil is not a more efficient way to release an object. It is less lines of code but just as heavy as [object setAttribute:nil].
3. Using dot syntax will not directly access the attribute on an object. While this is true in some languages, the actual call path for an Objective-C dot syntax accessor is:¹
   • Resolve the accessor selector from the call
   • The accessor method, if that does not exist
   • The attribute itself, if that does not exist
   • The unknownValueForKey: method is called last.

Why did Apple add it?

I have my own theories on why this nastiness was added to the language. It could be due to all of the windows hacks coming over to OS X and a desire to make them feel a little more comfortable.

It could be that a battle rages between the Carbon developer and the Cocoa developers and this was a concession to the Carbon developers since Carbon is going away.

It could be that while adding properties (a most useful feature of Objective-C 2.0), the developers decided “why not” and threw them in there.

We may never know the real reason behind adding these to the language. However it is clear that they are here to stay and I mourn their coming. They are a confusing addition to the language and cause developers new to our platform to bring bad habits with them.

Unfortunately they have made their way into Apple’s sample code as well as the language. This is truly unfortunate. As I have mentioned in the past, the sample code that Apple provides is not the best case solution; however many developers will think so. By adding dot syntax into these examples, it exacerbates the problem. New/young developers coming to the platform will see this dot syntax as the “right way” to do things and they will become a maintenance nightmare.

Maintainability

The last thoughts on this subject are with regard to maintainability. We often forget about this aspect when we are working by ourselves. However, maintainability is not just a factor when we hand off code to another developer, it is also a factor when we have to come back to our own code 6 months from now! I don’t know about you but when I look at code I wrote a year ago all I can think is: “That moron! What the HELL was he thinking!”

Since dot syntax is not as clear with regard to intent as message passing is, then we should avoid it for maintainability as well. Who wants to have to constant flip back to the header file while reviewing a piece of code to remember if we are talking to an object or a struct. Keep the intention clear, keep the code clear, and maintainability will follow.

Conclusion

In the end, it is a matter of preference. I hope that these topics have helped to show the negative effects of using dot syntax in Objective-C. It is purely syntactic sugar and adds nothing to the language. However, there are so many cons that I cannot suggest that anyone use it in any situation.

Thanks to our beloved iPhone (I do refrain from calling it “My Precious”), we have seen a sudden influx of Windows Developers. Now, when most of us came over to OS X and Objective-C from whatever platform we hailed from we did not assume that everything would be the same. Most of us are reasonable people and realize that OS X is different for a reason. Unfortunately, it appears that we are unusual people. Perhaps this would explain why we came over to this platform before it became “popular”.

With this recent influx of developers, most of whom we have welcomed with open arms, there are some who expect everything to be the same as the platform they came from and without bothering to learn or experiment have proclaimed our development tools to be “prehistoric”. This truly amazes me.

First, welcome to OS X and iPhone development. This is not the same language, platform and API you have been dealing with. Accept that or go home. We are not going to change it to suit you. We like it just the way it is.

We do things differently over here. Accept that or go home.

You have an interest in either OS X or the iPhone. To do a proper application for either one (barring a few edges cases), you need to learn Objective-C and Cocoa. Accept that … well you get the idea.

Objective-C has been around for a long time and it is a well thought out language. It is a runtime focused language and therefore things work differently than you are used to in your more structured environments.

Most of the time when these so called developers complain about Objective-C I simply roll my eyes and walk the other way. It is the sane thing to do. Never wrestle with a pig — you get dirty and the pig likes it. However, one particular “genius” has decided to out himself on his own blog. Of course I speak of none other than Jesse Ezell.

It is clear from this blog post that he has no interest in learning why OS X, Cocoa and Objective-C are different from his beloved Visual Studio but instead cries that it is too hard. I mean, seriously, complaining about NSObject vs Object? Perhaps he did not bother to learn that there is more than one root object in Objective-C? And then go to on and complain about MVC like its the devil’s music? Hopefully he is not the best that .net has to offer us!

But even with all of that, I read his post, chucked and moved on. It was not until he responded to the comments on that post that I decided to respond. It seems, from his perspective, that if a developer cares enough about their development environment to respond to his rant (and try to educate him!) that we are all “rabit elitists” out to get him!

First the word is rabid, not rabit. If you were using OS X you could have seen that it was misspelled and used the dictionary to figure out what the word meant. If you can’t even bother to run a spellchecker why bother writing at all?

Second, we care about our platform. We care about the code that we produce and how our applications look and are presented to the user. I know that is probably an extremely foreign concept where he comes from. But we care!

When developers come over here with preconceptions they do everyone a disservice. If they cannot even be bothered to pick up a book and read about the language to understand its fundamentals and its tools then why bother complaining about it. They are a waste of space. Move over and let someone who is willing to learn step up to the plate.

As for this developer’s ego and contempt for the developers on this platform — shame on him. His arrogance speaks towards his ignorance. He probably has written more lines of code in the past few years than I have. I have found that applications on Windows tends to take ten times as many lines of code as the same application would written on Objective-C and Cocoa. That does not make this developer better — if anything it makes him worse.

My suggestion is this: Pick up a book and read. You can even just read blogs like this one and avoid having to pay any money to learn. If a developer can’t be bothered then go home, we have no interest in you and certainly have no need for you.

As you can probably imagine, we have been heads down coding for the past month. Can I tell you what I am working on? Nope and if you are in the community you can guess why.

However, here is a hint.

What does a deadline look like?

And my desk to go along with that link:

Uploaded with plasq’s Skitch!

This is just another one of those things that seems like it ought to be a simple little code snippet and you’re there, but in actuality it’s just not the case. I am building an exporter for my application that will export a movie project in iMovie HD format. I want to mimic the file format exactly and one of the things I noticed about the directories that are stored inside iMovie HD’s custom format (select ‘Show Package Contents’ from the context menu in the Finder) is that they have custom icons assigned to them. So the problem to solve was how to do that programatically. Here is what I’ve found.
Read more

I’m a believer. I’ve used version control before, but Marcus has convinced me that with a little known version control system called Git, written by Linus Torvalds (the creator of Linux), version control is not just about versioning, it’s about expressing yourself with your code and collaborating with others, seamlessly.

As memory serves the only time I’ve used version control in a meaningful way the system I was using was Visual SourceSafe from Microsoft. I know. Blech! It’s awful! I’ve pulled code from many a CVS or Subversion repository, but I’ve never really used them in the way they are intended to be used. Now, thanks to Marcus, I realize that version control isn’t just about versioning any more. It’s a whole methodology/ideology that makes better programmers. Here is what I mean.
Read more

In this entry I am going to do something a little different. Instead of showing some wicked code, I am going to reformat one of Apple’s default templates.

Apple writes some amazing code. Unfortunately a lot of their templates demonstrate simply terrible coding practices. What is worse, people take these templates and assume that they are the proper practice for coding in Objective-C and propagate that poor code into their own projects.

The first example I am going to tackle is the AppDelegate class that is auto generated in the Core Data template. This is not the Core Data Document template but the standard application template.

Read more

For most simple applications using and managing resources is handled seamlessly and you don’t ever have to intervene programatically. There are times, however, as your applications begin to mature that you need to access resources directly. Doing so is pretty straightforward, but I thought I would document it here–if for no other reason than to have it written down somewhere for the next time I need it. I hope it might be helpful to you too.
Read more

As a follow-up to the previous blog post: Cocoa Tutorial: Using NSError to Great Effect; in this post I am going to demonstrate a few things that can be done with NSError objects that have been received. Specifically, how to add options to an NSError and how to (hopefully) recover from one.
Read more

In this continuing series on my own transition from a Mac application hacker to microISV (Independent Software Vendor), I am going to demonstrate how to create your own file format for your application. You’ve probably seen these types of files in popular applications such as iMovie HD (06′) or GarageBand or even xcode in which the actual files used are, behind the scenes, folders that the operating system treats as regular files. These folders/files have a special bit set on them that tell OS X how to deal with them. The goal of this post is to demonstrate how you can do the following:

• Create your own file format with your own file extension
• Register your file format with the operating system
• Provide application loading of your file that’s been double clicked in the Finder
• Write data and preferences back out to your application file
• Add resources such as media files to your application file

Read more

May 20, 2008
The T-Shirts for delivery at WWDC have been ordered. If there is enough interest I will setup a way to purchase CIMGF T-shirts (non-WWDC) directly from the site. Please contact me at marcus at cimgf dot com if this is of interest to you.

Last year I wore t-shirts for Zarra Studios and got quite a few compliments. These days I am becoming more known for this blog than anything else. Therefore, I am doing different t-shirts this year to celebrate this blog. As a reader of this blog you have an opportunity to purchase one of these shirts. They will only be run for WWDC so they are limited edition! :)

While the design is not complete yet, here is the first public draft of the T-Shirts:

Currently, the plan is to take them with me to WWDC and hand them out to those who have purchased one right after the keynote on Monday. If you are not going to WWDC but would still like to order a T-Shirt, that is also doable but naturally shipping costs will be involved.

The price per shirt will be $20.00 US. If you are interested in purchasing one or more, please contact me at marcus at cimgf dot com and I will work out the details. Right now I am processing orders manually but if they get too crazy then I may set up an actual shopping cart. Quantities are limited so act now! ;-)

Lastly, to follow Justin’s great idea. I am interested in trading T-shirts with other WWDC attendees. If you have a NEW shirt that you would like to trade for a CIMGF shirt, please contact me at marcus at cimgf dot com to plan a swap.

All Orders must be received and paid for by the 19th of May, 2008. Any orders received after that date can be shipped but cannot be delivered to WWDC.

Legal Junk

It is not my intention to make a profit on these t-shirts. I am offering them to readers at the approximate production cost. It is not my intent to mass produce these t-shirts with the goal of making a profit. If the production run comes close to or exceeds 500,000 t-shirts (wouldn’t that be amazing!) then the artwork on the back of the t-shirts may change due to restrictions in the license agreement.

I often find and therefore come to expect common problems in Cocoa to be easily solvable, however, there are times, like this, where I am a bit disappointed that the problem can be so difficult. All I need to do is copy a file. This is a simple task right? All you need is NSFileManager and a call to - (BOOL)copyPath:(NSString *)source toPath:(NSString *)destination handler:(id)handler and you’re good to go. Not so fast, city slicker. This one is going to take a bit more effort cause you want one of them fancy new-fangled progress indicators to show how much of the file has been copied. Well, if you want Cocoa to help you, you’re out of luck cause NSFileManager won’t do that for you, but with a little bit of effort you can get it to work with some… gulp… C APIs.
Read more

Undo support in Cocoa is fantastic but for those who have tried to mix it with Core Data know that it can be a bit frustrating. Generally, undo support can be ignored in most applications and it will “just work”. But when Core Data is added to the recipe then things get a bit confusing and more complicated.

Read more

In this post I continue to address topics of relevance to Macintosh programmers who are, like me, moving from being hackers to becoming independent software vendors (micro ISV). Today I am going to address adding copyright and version information to your about dialog and show you how you can update these dynamically. I also cover a few tips on formatting the text in your about dialog. There is more than one way to achieve these things, but my hope is to help others out there who need to accomplish these things and have no prior experience doing them on the Mac.
Read more

NSDecimalNumber is Objective-C’s solution to numbers that need to be very precise. The documentation defines it as:

NSDecimalNumber, an immutable subclass of NSNumber, provides an object-oriented wrapper for doing base-10 arithmetic. An instance can represent any number that can be expressed as mantissa x 10^exponent where mantissa is a decimal integer up to 38 digits long, and exponent is an integer from –128 through 127.

NSDecimalNumber

If you are dealing with currency at all, then you should be using NSDecimalNumber. However, since it is immutable and definitely not a primitive then it is difficult to use right? Well — yes — a bit. But if you do not want to see your $9.50 item displayed as $9.49999994 or something then you are better off using NSDecimalNumber right from the beginning. Otherwise you are going to be converting to it later and that is a LOT more painful.

Read more