Scott Stevenson January 22nd, 2007 @ 04:02 PM

It sure takes some guts for a Ruby programmer to stand up and call Objective-C “strange.” :) In all seriousness, Objective-C has some unusual things, but I think Ruby (which I love) wins the quirkiness contest.

If you really, really want to, there’s nothing stopping you from adding a category to NSObject which shortens the methods calls that you find too long:

@implementation NSObject (KozStuff) - (id)vfk:(NSString *)key { return [self valueForKey:key]; } - (void)sv:(id)value fk:(NSString *)key {

} @end

So you can do:

This is considered really ugly, but if you’re the only one who’s ever going to see the code, at least you know it’s available. Also, -valueForKey is prefered over -objectForKey nowadays.

I don’t know the true reason that nils can’t go in dictionaries, but my guess is that attempting to dereference nil would result in a crash since it evaluates to 0. NSNull, on the other hand, is a valid object which is a singleton. This allows you to traverse collections with more safety.

I’ve never seen a tangible case of “nil returning nil” causing a model to be engulfed in nil-ness, but maybe you’re doing something different. For whatever it’s worth, there are a number of things C++ programmers thought were bad in Objective-C but rarely actually materialize.

“there’s some serious gaps in the documentation”

Such as what, just out of curiosity? Certainly not everything is documented because there’s just a ton to document, but I’m wondering what you specifically ran up against. Sometimes things are there but just not easy to find.

I’ve been reading The Rails Way here and there.

Koz January 22nd, 2007 @ 05:00 PM

Hey Scott,

thanks for the comments, I’ll look into my hacked up templates to get them formatting correctly.

Once I adjusted to valueForKey and otherReallyReallyLongMethodNames I’ve definitely grown to appreciate it when reading Objective-C code. I’m not quite sure why, but I definitely feel that it fits in. Though I’m definitely not about to start naming my ruby methods similarly.

On several seperate occasions I’ve been completely stumped at how some part of my code is passing nil to a certain method, only to find that it was because of a bug in an entirely different part of my code which was blindly calling setSomething:something with something still uninitialized. Had the runtime behaved differently, I’d have seen an error at that point of the code, but generally I’ve been finding them two or 3 steps removed due to some hooks or callbacks in my code.

Koz January 22nd, 2007 @ 05:16 PM

As for the gaps in the documentation. I’m finding that it’s the high level stuff which is missing. Not just here’s how to tie up a controller and your model, but what the best practises are, the pros and cons of various approaches etc.

And yeah, rails lacks this kind of stuff to, it’s one of the things we’re trying to address with The Rails Way. Thanks for stopping by.

Grayson January 23rd, 2007 @ 01:58 AM

Being able to pass nil to a method is entirely valid in Objective-C. If you’d prefer to catch instances where an method is being called with nil, you should throw an exception at the start of the method. I find that throwing nil around is very handy and often call kvc methods with nil in order to update bindings and whatnot. I just catch nil early and return. I know working with nil may seem a bit out of place to many but it simplifies my code greatly once I embraced it.

Jesper January 23rd, 2007 @ 02:51 AM

Grayson: Koz did not have a beef with sending nil as a parameter to a function (that’s perfectly legal in any language, whether it’s nil or null).

Koz had a problem with being able to call methods (aka “sending messages”) to nil:

NSString *x = @”foo”; // releases x x = nil; id y = [x release]; // x is nil, and calling release on nil just returns nil, so y is now legally and correctly nil

Jesper January 23rd, 2007 @ 02:53 AM

And again, minimally and with line breaks:

id x = nil; // ‘id’ just means ‘any object’

id y = [x release]; // x is nil, and calling release on nil just returns nil, so y is now legally and correctly nil

Brian January 23rd, 2007 @ 03:32 AM

This may be putting the cart before the horse, but the first thing that popped into my head when thinking about not being able to insert nil into arrays/dictionaries were the methods such as [[NSArray alloc] initWithObjects:object1, object2, nil] which use nil as the delimiter to tell when to stop adding objects from the vararg list.

Another example is if you call objectForKey: on an NSDictionary and there is no value for that key, the method will return nil. If you were allowed to insert nils into a dictionary, you couldn’t tell the difference between there being a nil value and there being no value for a given key.

It took a little getting used to when I first started, but I got used to messages to nil returning nil pretty quickly, and I actually kind of like it now. If you’re aware of it, you can use it to remove a whole lot of “if (foo == nil)”s out of your code, making it much cleaner looking, along with being able to nest method calls and not worry about having to check for nil on every return, just the end result.

Paul Ferguson January 23rd, 2007 @ 07:35 AM

Actually, I’m NOT looking forward to garbage collection. Retain/release helps me understand the semantics of object life, which is important architectural information. The rule of retain/release are very easy to internalize (every retain must be matched by a release or autorelease within the same scope), and while it is possible to slip up and miss once in a while, it soon become second nature. The discipline this rule enforces has helped me avoid numerous stupid object management mistakes.

Maybe I’m somewhat of a Luddite on this issue, but I consider retain/release a key feature of Objective C and the foundation framework.

Marc Charbonneau January 23rd, 2007 @ 08:06 AM

Messaging nil is actually one of the things I miss the most when I’m not working in Objective-C. There are many times when I don’t care about an object, and having to throw in an extra if statement just to see if it’s nil/null just leads to bloated code.

Keep in mind that messaging nil does not work when the method returns a struct or a floating point value; only for ints and object pointers.

Henry Maddocks January 23rd, 2007 @ 08:45 AM

Cocoa is a lot of fun, but there are a few irritating things… not being able to build without warnings for example, and yeah the docs suck. At least in Rails favour you can go read the source.

The funky function names take a while to get used to and it’s naff that the args have to be in the correct order. I much prefer the hash method that rails uses, even if it is a hack. There’s been some talk of Ruby getting named args soon. Best of both worlds?

For true programming nirvana try RubyCocoa. I’ll give you a guided tour at the next wellrailed meeting if you are interested. If you’re going to be doing a bit of Cocoa stuff it might be worth joining WelDev. It’s a Mac programming group in Wellington in a similar, but more chaotic style to the Rails group. Let me know if you want the details.

Here’s another post along the same lines. http://mooseyard.com/Jens/2007/01/in-which-i-think-about-java-again-but-only-for-a-moment/

Koz January 23rd, 2007 @ 09:42 AM

Marc: With ruby, nil is an instance of NilClass, which means you can send it messages. This is fantastic and I definitely agree with you that that kind of behaviour is important.

My objection to objective-c is that you can send nil any message, with any parameters and get the same result.

Brian: I’m sure that the reason is something along those lines, but ruby and java take care of that with a separate method for determining whether a dictionary has a given key. dict.has_key?(“foo”)

Paul: Sorry, but you’re wrong. JWZ’s article, Joel Spolsky’s sidebar all indicate the benefits of GC. It’s not that manual memory management is impossible to do, it’s that your time could be better spent elsewhere.

Paul Ferguson January 23rd, 2007 @ 11:45 AM

No, I’m not wrong, I just have a different perspective on software development than you. Some people only drive cars with automatic transmissions, while others still prefer to shift gears manually.

Neither JWZ or Joel Spolsky really focused on the issue of programming discipline as it relates to memory management; having used GC languages in the past, I know how easy it is to write badly designed code that consumes an ever increasing amount of memory.

Koz January 23rd, 2007 @ 01:22 PM

There’s nothing about manual memory management that stops you from writing code which consumes gigs and gigs of memory. In fact you’re far more likely to do that than you are with a nice GC.

Having said that, we’re not going to convince one another, and I do acknowledge that some people really do like focusing on that level of their application. It’s just I’m not one of them, and my customers don’t want me to be either :)

All the best