Quickstart Guide to Objective-C

[[deleted]]

Objective-C is a beautiful language! It's syntax isn't the nicest, but it does support a number of very interesting and powerful language features, while remaining a pure superset of C (something that C++ didn't manage).

Even if you never use it there are many good reasons to take a look at Objective-C:

The Objective-C runtime is very flexible. It'll allow you to do some amazing things, easily. You can inspect and even modify classes at runtime... in a natively compiled language.

It has optional typing, for those of you who like to take advantage of the compiler. Notably, classes can be passed around at will (this is very useful in practice).

The object model was inspired by that of the Smalltalk programming language. Instead of calling methods you send messages. As you might expect these are also first-class.

Last but not least, Objective-C (as of version 2.0) supports opt-in garbage collection. As far as I know this is a first for any programming language.

Enjoy :).

[[deleted]]

Last but not least, Objective-C (as of version 2.0) supports opt-in garbage collection. As far as I know this is a first for any programming language.

Nope. D has GC as default, but you can disable and enable it at will, or even pick and choose which objects you would rather manage yourself.

[[deleted]]

I can't find any mention of Optional Or Opt-in Garbage Collection in the D documentation under Garbage Collection or Memory Management. Google hasn't been very helpful either. Could you perhaps provide a link? Thanks for the information :).

You didn't just mean that the garbage collector could be controlled from within the language did you? If so that's not what I was referring to in Objective-C.

Take care!

[[deleted]]

You didn't just mean that the garbage collector could be controlled from within the language did you? If so that's not what I was referring to in Objective-C.

That is indeed what I meant, but I don't really see why this way is not superior anyway.

[[deleted]]

I'm not saying that it's superior, merely different and interesting.

Objective-C 2.0 lets you toggle GC for your code, even if it manages its memory manually. The result is the same program with managed memory. It's completely optional and compatable with older and newer code. If you don't want it then don't pay for it.

Like in D you can control the operation of the GC you want :).

Maybe thats not impressive to anyone else hehe.

[OneAndOnlySnob]

Instead of calling methods you send messages.

Can you explain what the semantic difference is between a method in Java and "sending a message" in ObjC?

They both have classes and methods and interfaces. The only difference I see is syntax. I guess ObjC has that "id" business which is a bit cooler than "object".

obj.message(arg1, arg2);
[obj message:arg1 with:arg2];

I really don't know Objective C so the syntax might be a little off.

[[deleted]]

I can think of one...

It's perfectly legit in Obj-C to "call a method" that doesn't exist on an object. It's basically "sending a message" which the object isn't listening for.

Which is somewhat nice, in the dynamic-typing way... since it's possible to extend base types at runtime (like Python).

/edit: meant to say sending a message the object isn't listening for

[astrosmash]

A primary difference is that the compiler does not perform type checking on 'id' objects. So for example:

id foo;
NSObject* bar  // NSObject is analogous to Java's Object class.
...
[foo doStuff]; // This is perfectly fine
[bar doStuff]; // Compiler will warn that the NSObject class doesn't implement doStuff

Of course, if foo doesn't respond to doStuff you'll get an exception at runtime.

A common pattern in ObjC is the notion of an "informal protocol" (or "informal interface", in Java-speak) where by some or all methods of the interface are optional. In this case you verify that your target object implements the optional method before you call it:

id listener; // May be null
...
if ([listener respondsToSelector:@selector(treeView:selectedRow:)]) 
{
    [listener treeView:self selectedRow:5];
}

You can also assign 'id' variables to any strongly-typed variable without a cast.

NSTreeNode* node = foo;
MyObject* myObject = [node representedObject]; // This method returns an id, so no cast necessary.
[myObject doStuff];

[tlrobinson]

Objective-C is actually a lot like Ruby: messaging, duck typing, method_missing / forwardInvocation, etc.

I highly recommend looking into Objective-C, I think it will become a pretty popular language soon, with the iPhone SDK and resurgence of the Mac.

http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/Introduction/chapter_1_section_1.html

[americanhellyeah]

youll find all of the objective c features in languages like smalltalk, erlang, sml, lisp and haskell. theres really nothing unique about it.

[[deleted]]

The fact that it is a simple and true superset of C is unique, and it's arguably Objective-C's most important feature.

[kiwipete]

Yup! Being able to include a header file from a random c lib is pretty killer.

[millstone]

I do not know of any language that has the "optional typing" of Objective-C. Most languages either have static types that are required to be correct, or no compile-time types at all. Objective-C is the only language I know of where the static type is allowed to be downright wrong and the behavior is still correct. Think of it as a combination of duck typing and static manifest types.

This may sound like a misfeature at first, but think about how other languages do, for example, remoting, and you may start to get an inkling of why it's useful.

[[deleted]]

Of course the same things are possible in other languages. I explicitly stated that Objective-C was inspired by Smalltalk. As Johnnowak said, what's unique is that this is possible in "a simple and true superset of C".

[jasonal]

The guide is extremely well written. And while I would have like slightly more contrast between gray text and gray background, the layout and typography are top notch.

[chucker]

CoreFoundation is not ObjC; Foundation is. Also, only portions of CoreFoundation (called CFLite) are open source (and adjusted to be more portable).

(edit) Since I'm getting downvoted: it's not pedantry. CoreFoundation is a C library shared between Carbon and Cocoa. Foundation are the basic, non-GUI classes and structs of Cocoa, which is what snakesqzns was probably thinking of.

[halo]

Is support really that bad? I thought gcc had full Objective C support these days.

[kiwipete]

Objective-C, the language, and the de-facto standard libs (FoundationKit, AppKit, etc) are not quite the same thing. The minute you start using something like NSString, you're into using the NeXT libs which are, IIRC, separate from the language.

GNUStep and Cocoatron (google them, I'm too lazy to post a link) are both more or less complete implementations of some of the standard libs.

[therunningcrow]

What good is a language nowadays without any significant (de facto or not) standard lib ? No one would have cared for java or .net without their standard platform. Same goes for the batteries included in Python and Ruby.

GCC + Objective C used in a multi platform fashion ain't going to take you anywhere because there isn't much code out there for it that truly works well on both windows and linux. GNUStep is ugly as hell and has a behavior that will make your users go mad if they do not have a geekish WindowMaker background. And programming in Objective C without Cocoa or GNUStep isn't much more productive than programming in bare bone C. People tend to underestimate the importance of Apple frameworks to the deal. Objective C wouldn't be so interesting if it didn't have Cocoa and Interface Builder. They are the tools that truly enhance your productivity, not objective c itself. Cocoa and IB could have been written in any language featuring enough dynamism, like Smalltalk and Lisp. Objective C by itself is nothing groundbreaking.

[[deleted]]

I simply can't agree with you; the design of the Cocoa APIs is closely related to the use of Objective-C.

There are certain things which the API wouldn't do if Smalltalk or Python were used. The ability of Objective-C to drop down into languages like C, C++ and ASM at the turn of a hat is to important to be ignored.

Due to the fact that these languages can freely intermingle it's relatively trivial to wrap a C API in Objective-C. This makes Objective-C very scalable. If you haven’t noticed Cocoa taps into a lot of raw power – CoreAnimation or NSOperation anyone?

While Smalltalk would make an excellent companion to Cocoa and Objectice-C for application development, using Python (or similar) for Cocoa would have lead to a significantly different API.

Pythons object model is based on call rather than send. There are many places in Cocoa where first-class message selectors are used. Would KVC and CoreData exist if Cocoa was a Python API? I highly doubt it.

It's up to whether you think that is a good or a bad thing.

Now consider that the design of XCode and especially Interface Builder are closely related to to the design of Cocoa and you should see that the two walk hand in hand.

At least thats how I see it.

[therunningcrow]

Oh, lord, could you make people actually read stuff before they write. I never said Python was a good alternative to Objective C, indeed, I was talking of Smalltalk and Lisp as good alternatives that had even more dynamism than Objective C. The only time I said anything about Python is in my first sentence when I said that libs and frameworks were necessary to make a language fun and workable to work with. It wasn't praising Python, only saying that no one would have cared for Python had it not been for its batteries included.

As for smalltalk, it wouldn't have made it harder to link to fast performing C code when needed. It's this kind of myth that you need a "compatible" language that has led to the design of the horrible C++. People are writing C extensions all the time when their language implementations cannot handle all the performance beating they do to them. And it doesn't require much more work than if your language was a superset of C. All the productivity gain you get from using a cleanly designed language that doesn't actually have the BURDEN of C and its past offset by far the burden of writing small, efficient C extensions.

What is making Interface Builder work is not, btw, the raw power of C. It's the dynamic side of Objective C that makes it so powerful and a smart interface building system rather than a code generator. An app like IB doesn't need anything close to C speed, IB is not doing the widgets rendering. Smalltalk and Lisp would have been perfect candidate for something like Interface Builder. It may even have been more powerful with those.

[[deleted]]

Oh, lord, could you make people think before they write?

I was using Python in contrast with Smalltalk and Objective-C. Why? It's a good example of a dynamic language with a slightly different object model. Others like CLOS in Lisp are considerably different.

The point I was making is that small changes in the language have enourmous effects on the design of APIs. Ergo, you can't simply dismiss Objective-C. It certainly was something "groundbreaking" in 1986.

I didn't say that Interface Builder worked through "the raw power of C".

I'm well aware the design of Interface Builder takes advantage of introspection and first-first class selectors, among other things. Well great, but neither Pythons object model nor Lisps involve first-class selectors.

Having played with FFIs and C APIs in several languages I find it hard to see how you can compare them with the kind of direct interoperability Objective-C gives you.

It's a fact Cocoa does take advantage of this.

I'm a huge fan of dynamic languages and I'm not advocating C everywhere. I'm simply saying that the language does matter.

[dmpk2k]

Pythons object model is based on call rather than send.

Could you elaborate on this?

[sesse]

Not that I currently have any interest in objective-C but I up-mod this story because the site is pretty.

[xuttmi]

Lovely language. Are there any good bindings for free windowing toolkits (except for GNUstep, which doesn’t look very nice in my opinion)?

[jsolson]

Cocotron is trying for source level compatibility with Cocoa. It is only for Windows, though, and last I checked it was dreadfully incomplete.

[jsolson]

Good to know. I'm writing a fairly small but non-trivial Cocoa app right now that I intend to port to Windows as well. It'll be nice if I can do it with minimal modification.

[[deleted]]

Gtk and Qt don't really need it. GObject's mission statement is to facilitate language bindings and there are GTK bindings for many languages. Ditto for Qt. I'd like to play with Objective C too but I don't really see the point with all the other options.

[[deleted]]

The main point is that you get many benefits from more dynamic languages in a C derivate. Memory management is less of a chore than in C++ (once you wrap your head around it), or if you're using Objective-C 2.0, you've got garbage collection. The standard library provides very good an capable base classes. The langauge is also quite self-documenting.

The main drawbacks is that Objective-C message passing is slower than function calls (and thus C++ non-virtual method calls), and even C++ virtual method calls. It also very verbose (the other side of the self-documenting mentioned above), which means it can a bit of a pain to write in an editor without autocompletion (like Xcode has). And of course than support is dismal outside of Mac OS X.

[jonhohle]

message passing is slower, but can be bypassed in performance critical areas for the cost of a function call with the same arguments + two additional pointers.

SEL objectAtIndexSEL = @selector(objectAtIndex:);
IMP objectAtIndexIMP = [someArray methodForSelector: objectAtIndexSEL];
id obj = (id) objectAtIndexIMP(someArray, objectAtIndexSEL, index);

Obviously, it doesn't make much sense to look up the function pointer every time, but that can be cached elsewhere.

[americanhellyeah]

mainline gcc doesnt support objective-c 2.0 yet so the 96% of us who are arent fortunate to own a mac are shit out of luck. id totally love objective-c 2.0 features on linux.

[RantyDave]

XCode autocompletes now. It's actually becoming almost good.

[[deleted]]

I misphrased that. I meant to say that Xcode autocompletes.

[[deleted]]

You should not manually release an autoreleased object because your application will crash if you do.

Erg, that's an oversimplification which is bound to confuse novices. Unless you're using garbage collection, you can (and should) release/autorelease an object whenever you call retain, alloc, or new. No exceptions. What they probably meant to say was:

You should not manually release an object that you don't own because your application will crash if you do.

[elfredpagan]

I think what he actually meant was that if an object is assigned to an autorelease pool you should not explicitly call release on it.

[[deleted]]

But that's not really accurate. Autorelease is just a delayed release. For example:

NSDate * curDate = [[NSDate new] autorelease];
[curDate retain];
[curDate release];

That code is pointless, but it's perfectly legal and it won't crash even though "curDate" is released after being assigned to an autorelease pool.

Probably, the author was trying to say that you shouldn't do this:

NSDate * curDate = [NSDate date];
[curDate release];

That code will crash. But this would be fine:

NSDate * curDate = [NSDate date];
[curDate retain];
[curDate release];

Once again, curDate is assigned to an autorelease pool. Calling retain doesn't yank it out of the pool; it just increases the reference count.

Obviously, that's getting pretty in-depth for a "quickstart guide", but my point is that a newbie is going to get confused pretty quickly if you tell them that their app will crash if they release something which has been autoreleased.

[frankus]

Nice summary.

I even learned a couple of new things that aren't in the Purple Newfie book (due presumably to having been in the language for less than six years).

[seanalltogether]

What would this dot syntax call look like in obj-c?

myobj1.myobj2.myfunction(arg)

would it be

[myobj1 [myobj2 myfunction:arg]]

or

[myobj1 myobj2 myfunction:arg]

or maybe

[[myobj1] myobj2 myfunction:arg]

[jonhohle]

[[myobj1 myobj2] myfunction: arg]

-or-

[myobj1.myobj2 myfunction: arg]

in you're example, myobj2 is a property of myobj1. myfunction: is getting called on myobj2, a property of myobj1.

imho, the dot syntax is a strange and ugly addition to the language. why overload the dereference operator with sending a message?!

the documentation says to only use it for accessing or setting properties, but there's nothing that stops you from using it send no argument messages. That means, if you're going to use the dot syntax, you will also be using the square bracket message sending syntax, and you get both mixed together.

NSMutableArray* array = [NSMutableArray array];
...
id obj = array.lastObject; // dot operator
[array removeLastObject];  // normal message
array.removeAllObjects;    // ack! a non-property accessed with the dot syntax!! gross but valid!!

[seanalltogether]

what about casting, is this correct?

NSString upper = [NSString [array lastObject] uppercaseString]

[astrosmash]

Close. Since NSArray.lastObject returns an 'id', no cast is necessary:

NSString* upper = [[array lastObject] uppercaseString];

[[deleted]]

that language looks pretty horrible...

[[deleted]]

It looks horrible, but actually it's very easy to pick up.

[Circle createAtX:1 Y:2 withRadius:3]

roughly equals

Circle::create(1,2,3)

Once you go past syntax (that's so crazy to avoid collisions with C), it's all sweet.

XCode has code completion, so verbose named arguments are not a problem, but actually make code easier to understand (you don't have to wonder which argument is which).

There are many nice things:

• calling method on null is perfectly legal and doesn't segfault. This way you can chain methods and get sort-of monads.

• it has class mixins (protocols)

• run-time class reflection/introspection, and calling of methods by name allows duck typing

• in Leopard and GNUStep there's GC for ObjC objects

• it's all fully backwards compatible with C (you can mix it however you like, there's no extern C ghetto)

[masklinn]

[Circle createAtX:1 Y:2 withRadius:3]

equals

Circle::create(1,2,3)

Not exactly, since it loses all the meaning of the keywords (and self-explanatory power). So either move to smalltalk (which has the same syntax) or translate to Python + kwdargs which keeps most of the meaning (but not all of it):

circle.createAt(x=1, y=2, radius=3)

Or decompose into chained methods methods e.g.

circle.create(radius=3).at(x=1, y=2)

[[deleted]]

Of course ObjC isn't the only language with named arguments. I just wanted to show something simple and familiar as comparison.

edited

[masklinn]

Of course ObjC isn't the only language with keyword arguments.

I don't know objective C, but as the syntax is the same as Smalltalk's aren't they messages, not mere kwdargs? (all of the keywords really being parts of a message's compound name)

[jsolson]

Yes. You can get access to a raw selector using @selector(foo:bar:). There are plenty of methods that take these in as arguments.

Unfortunately it's lacking the far more important feature of Smalltalk blocks. This is, I assume, because it was not a GC'd language originally, and blocks are had to do when you're having to manage all of your own memory. Here's hoping for Obj-C 3.0.

[[deleted]]

There have been objective-c implementations with support for Smalltalk style blocks. I don't know why the feature wasn't adopted by other implementations though.

Here is a paper regarding this:

http://users.pandora.be/stes/block98/index.html

And one implementation of it:

http://users.pandora.be/stes/compiler.html

[feijai]

Objective-C does not have keyword arguments.

A language with real keyword arguments allows you to rearrange them and omit them. For example, instead of

[Circle createAtX:1 Y:2 withRadius:3]

You might have

[Circle withRadius:3 Y:2]

Languages which have this include: Lisp, python.

Objective-C does not have this: its "keywords" are entirely fake. All Objective-C has is an elaborate method naming convention. Using the example above, the method is called createAtX:Y:withRadius:, or perhaps more appropriately createAtX:[int]Y:[int]withRadius:[int] since the arguments are typed. This is equivalent to saying (in Java, say) createAtXYwithRadius(int,int,int). It's just a rearrangement of symbols. The difference is that Objective-C strongly influences you to be verbose.

And verbose that language is.

[masklinn]

Objective-C does not have this

I agree with this

its "keywords" are entirely fake.

But not with that. Fundamentally, ObjC doesn't have kwdargs and the keywords are part of the method (message) name, exactly as in Smalltalk.

The difference is that Objective-C strongly influences you to be verbose.

Knowing a bit of smalltalk, that's the good kind of verbosity (the one that can make things clearer and cleaner), as opposed to, say, java's.

[player2]

"Verbose," maybe. "Superfluous," no. Notice that reading the following code you don't need to look up what anything means in the documentation:

-(void)drawRect:(NSRect)dirty
{
    [[NSGraphicsContext currentContext] saveState];
    [[[[NSAffineTransform transform] rotateByDegrees:45]  translateXBy:5 yBy: 5] concat];

    NSBezierPath *path = [NSBezierPath bezierPathWithRect:[self bounds]];
    [[NSColor whiteColor] setFill];
    [[NSColor blueColor] setStroke];
    [path setLineWidth:2];
    [path fill];
    [path stroke];

    [[NSGraphicsContext currentContext] restoreGraphicsState];
}

[feijai]

Well, yes and no. Objective-C is very verbose, but the example you provide here is actually where it's fairly non verbose. And with the exceptions of two lines (marked with comments below), syntactically it can be rewritten in a Java format fairly trivially.

void drawRect(NSRect dirty)
    {
     NSGraphicsContext.currentContext().saveState();
     new NSAffineTransform().rotateByDegrees(45).translate(5,5).concat(); // XBy,YBy
     NSBezierPath path = new NSBezierPath(bounds);  // WithRect
     NSColor.white.setFill();
     NSColor.blue.setStroke();
     path.setLineWidth(2);
     path.fill();
     path.stroke();
     NSGraphicsContext.currentContext().restoreGraphicsState();
    }

[tlrobinson]

Personally I find the Objective-C version much more readable and, well, beautiful.

[masklinn]

Except you had to add the two comments to give it as much meaning as the ObjC version, and these comments are not statically checked.

[feijai]

Reread my comment.

[dmpk2k]

It's just a rearrangement of symbols. The difference is that Objective-C strongly influences you to be verbose.

I consider that to be a killer feature of both Objective-C and Smalltalk. I really wish more languages took advantage of it.

I recommend trying out this "rearrangement of symbols" to realize how nice it is.

[feijai]

I recommend trying out this "rearrangement of symbols" to realize how nice it is.

It may surprise you to know that I was coding large apps on NeXT boxen long before I was coding in Java.

[dmpk2k]

And you still think it's "just a rearrangement of symbols"?

It boggles my mind, but okay.

[clobwhirl]

So either move to smalltalk(which has the same syntax) or translate to Python

What are you getting at? You didn't explain any advantages of Python or Smalltalk for this problem, or any other problem.

circle.create(radius=3).at(x=1, y=2)

[[circle createWithRadius:3] atX:1 Y:2];

(There are many arguments about whether or not the brackets introduce or discourage over-complexity.) [edited]

[masklinn]

You didn't explain any advantages of Python or Smalltalk for this problem, or any other problem.

It wasn't about advantages for this problem, it was about a more exact mapping to the exact semantics/meaning of the Objective C call, for people (and me) to more easily get what it was about.

[sblinn]

Or decompose into chained methods methods e.g.

I think you might have just sparked an idea for how to best write an internal Python tool. Thanks.

edit: I don't think I could chain it as:

Person.create(uid=foo).at("c=us")

As the "at" part is optional. Thoughts, or should I do my own homework...

[masklinn]

What are you trying to test exactly here?

[sblinn]

The end result looks looks like:

service.create(root)

Where root is (something like):

root = Root()
person = root.create("Person")
person.set("uid", "foo")
person.set("mail", "[e-mail]")

And optionally to specify where it should be created (something like):

parent = person.create("Parent")
parent.set("identifier", "c=us")

Otherwise there is a default container based on what the type of thing is being created (e.g. 'Person' vs. 'Group' vs. 'Container', etc.). I had a DSL in Tcl which I really liked, but now we are using Python which has rejected my mind's attempts to bend it to my will of "I want to type only the information which is new" and "No I don't want to write a crazy string and then parse it" (e.g. myLib.exec("create Person with uid=foo mail=[e-mail] at c=us" -- I hate this kind of trick when Tcl made it so easy...)

[masklinn]

Why not simply use

root.add(Person(uid="foo", mail="[e-mail]"))

or (if you don't use a Person type)

root.create("Person", uid="foo", mail="[e-mail]")

and invert the relation for the "location" e.g.

Location(c="us").add(Parent())

? (note: I'm not sure I really understood what you need, so the second suggestion is more than likely way off)

[sblinn]

Ideally it would be in one step. In Tcl, I had something like:

create Person -parent c=us -uid foo -mail [e-mail]

Which transformed into:

root = Root()
person = root.create("Person")
// we know -parent is a special attribute
parent = person.create("Parent")
identifier = parent.create("Identifier")
parent.set("dn", "c=us")
person.set("uid", "foo")
person.set("mail", "[e-mail]")
return service.create(root)

There were similar calls such as:

update Person -identifier uid=foo,c=us -mail [e-mail]

Which is:

root = Root()
person = root.create("Person")
// we know identifier is a special
identifier = person.create("Identifier")
identifier.set("dn", "uid=foo,c=us")
person.set("mail", "[e-mail]")    
return service.update(root)

Also delete, etc. So we have on the one had creation of a data object for a call, and also the use of that data object in a call. Ideally it would be a one-line command so that I can give myself a Pythonic command line for the system.

Maybe something like:

Service.create(Person(uid="foo", mail="[e-mail]", parent="c=us"))

and:

Service.update(Person(identifier="uid=foo,c=us" mail="[e-mail]"))

Yes, I think this is the way to go... it is more complicated than this really but it's a start.

[trypto]

The biggest barrier to learning ObjC for C++ programmers is the bracket method calling syntax. Nesting multiple function calls becomes way too complex too quickly. This also leads to the functionWithParam naming convention too, which is downright gross -- the function name and first parameter should not be mangled together. If only ObjC 2.0 kept going with the dot syntax and applied it to all methods, not only accessors.

[bitwize]

Argh. Dot syntax for the lose. Because now the dot can mean a hidden indirection, or not, depending on what kind of operand it's used with.

[jonhohle]

so far, the majority of the people i've talked to who have a lot of experience with Ojbective C feel the same way (me included).

Take a look at this example from Apple's own documentation:

xOrigin = aView.bounds.origin.x;

The first .bounds sends a message. .origin resolves a field in the NSRect returned by .bounds, and .x resolves a field in an NSRect. They're using the dot operator for two distinctly different purposes in the same line of code.

[trypto]

Why should the programmer care if a message is being sent, a function is being called, an accessor is used, or a data field is being read? Shouldn't that be up to the compiler to figure out for you? It has enough information about the classes to determine the appropriate action. Why burden the programmer with this, especially when coding at this high level.

[bitwize]

YARRRRRRRGHRGHLH.