Objective-C Syntax
July 20th, 2008
I’m still trying to learn Objective-C and Cocoa here, and coming from Ruby, its an interesting experience.
Method calling Syntax
I simultaneously love and hate the method calling syntax. Take this for example:
[UIColor colorWithRed:1.0 green:1.0 blue:1.0];This create an instance of the UIColor class with red green and blue values as specified, in this case white. I do like that the parameters are labeled, and I like that better than simply passing in a list of anonymous argument that most languages give you.
But what I don’t like is the method name being forced to mingle with the arguments. Semantically, red, green, and blue are all equal things. However I am forced to prepend the declaration of the red value with this colorWith prefix. The named parameters actually are the method name. According to the langauge internals, the name of this method is:
colorWithRed:green:blue:Here’s how I might do the same thing in ruby:
UIColor.new(1.0, 1.0, 1.0)Although, this requires some formal knowledge that the order of arguments is red, then green, then blue. But I can easily remember this since its a basic language feature.
Usually I don’t mind long method names, but when handling things as simple as initialization, it seems like I should have to look up the syntax. Long ruby method names aren’t too much of a problem, because they only have one part. Objective-C methods tend to be more verbose, and its hard to know where the arguments go and what type the arguments are supposed to be.
The result is that I can’t possibly imagine writing Objective-C without a code completing IDE. I have written huge amounts of ruby in Textmate, and really don’t miss code completion much. Maybe I just have to get used to the IDE mindset.
Objects and non-Objects
Ruby has spoiled me. Everything is an object in ruby. A string, a number, a chunk of code, everything. Even a class is an instance of the class Class.
In Objective-C the story is different. An object is an instance of a class that inherits from the NSObject class. Basically this means that the only things that are objects are things that are provided by Cocoa. Other things that are provided by the underlying C, like floats, strings and whatnot are not objects. Although, to be fair, Cocoa provides object based wrappers for most of the C non object primitives, but its not always worth the overhead to use them for simple stuff.
This makes the syntax a bit of a mess. The bracket method calling syntax only works on objects, because a non object (I dont even know what to call it) cant have methods at all. And then you have calls to C functions like:
UIGetCurrentGraphicsContext()Which doesn’t even use the bracket syntax at all. I’m sure I will get used to all this, but I can’t help but feel this language would be a lot more fun if everything was an object. I think most people go from something like C to ruby, but I am going the other way around, and it’s odd. We’ll see where this goes.
July 31st, 2008 at 08:14 AM
I’ve got to agree with you on the syntax thing.. I’m learning Objective C from the background of 10 years of Java development, and the syntax is really confusing for me too.
I get the optional named parameter declarations now- and how they form part of the method signature. But I’m still really confused about some of the syntax I see. I’ve seen methods where there are parameters both before and after the method name: e.g.
-(NSString)name1:(NSString)var1 methodName :(NSString)var2 name3:(NSString)var3 { ... }
I’m at a loss to know why you might choose to put parameters either side of the method name like that – but this was in sample code from Apple, so it must be ‘standard’! In Java this would always be:
String methodName(String var1, String var2, String var3) { ... }
August 7th, 2008 at 10:59 AM
First of all, there is no difference between the method name and the argument identifiers. Objective-C only sees a method with the name of
name1:methodName:name3:.This appears to be often used for delegate methods. And I think it works in this context. You are sending a message to some object, that some other object did something. So having the first argument being the object that performed the action makes sense. And it reads kind of well.
But this is confusion that happens when the semantics of action and argument get jumbled together.
November 1st, 2008 at 10:52 AM
old fart38 here, looking at this Objective-C…. It had labels on the keys for functions. It new from the position on the line wether you meant the command ‘print’ or the letter “s”. This was both confusing and intelligent but it made learning to program it and debugging a nightmare. (especially since it only displayed 16 char of the line at a time, calculator style) I think that the computing world has figured out that the syntax of: retVal=objectInstance.method(parameter1,parameter2, etc…) is by far the most easily read/compiled way to work with objects, and the ability to [optionally] name arguments instead of position based assignment makes for even better code clarity. The precompiler has no problem re-arranging the arguments and stripping the lables so no performance hit there… Is there any excuse not to do something like that (precompiling) to strip un-needed overhead from native c calls (non-objects as he called them) to remove any performance hit with complete OOP syntax? I think not…
var sound Applause=OnSoapBox.CallToAction(Background:”all computer languages”,Desire:”I Propose a new open source OOP language that will be understandable by all!!!”,Result:”Call it Clarity”)
November 1st, 2008 at 10:54 AM
whoops, move this phrase to the top: I worked on a cannon computer in the late 70’s.
November 1st, 2008 at 10:56 AM
There are only 10 types of people, Those who understand binary and those who do not… lol
June 17th, 2009 at 02:59 PM
@Mike O’Connor
Just FYI the code you posted: -(NSString)name1:(NSString)var1 methodName :(NSString)var2 name3:(NSString)var3 { ... }
This is a method definition, the (NSString) before the method signature is not a parameter, it is an identifier for the type of value returned by the method.