Hacker News Reader

Comment by bonch | Hacker News Reader

Ignoring the disputable claims that it's unpopular or has a slow learning curve (you can describe Objective-C's additions to C in a single page), there's no evidence to claim that Objective-C is about customer lock-in, especially when you can use so many alternatives including the Apple-funded MacRuby.

Apple uses Objective-C because they have a lot of code written in it, and it has served them very well. iOS is the most popular mobile platform for third-party development. The dynamic nature of the language has enabled the implementation of some useful features like key-value-observing, while the ability to drop to C retains the flexibility of system-level programming.

Even the memory management criticism is overblown. You merely have to follow an easy list of four ownership rules. That's if you're not using the garbage collector that came out four years ago with Leopard.

View on HN

If you follow those "easy rules," how do you handle race conditions between weak references held to avoid retain cycles and the execution of those weak reference's -dealloc methods? There's nothing to stop the weak reference's -dealloc from racing with messages to that weak reference.

Or, how do you handle the fact that -dealloc can be called on whatever thread calls the last -release, even if you make an effort to only send messages to an object on the main thread (Which will trigger implicit retain/release unless you're incredibly careful). Almost all of the GCD examples out there are subtly broken because of this.

As for GC, I look forward to actually being able to use it on iOS.

I can't address your first point because I haven't used GC yet, but your second seems like a contradiction. If you're releasing from a background thread then you are sending messages from a background thread. You can easily put code in our object's release method to fix that, though. "If not main thread, call self on main thread."

This is a hack, not a general purpose solution, as it requires modifying the class, and and still must be done carefully to avoid accidental retain/release.

Calling retain/release from a background thread will happen simply by using blocks, gcd, or performSelector: APIs, as designed, to attempt to schedule execution on the main thread. Avoiding the issue requires exquisite care, unless you actually want to modify every single class that you may access an instance of from a background thread (such as GCD).

As to the first point, it applies in a NON-GC environment, where you hold weak references to delegates a(nd deregister them in dealloc.)

Sorry, the term "weak reference" threw me. So you mean you have pointers to objects you have not retained, and you "deregister" (set them to nil?) in your dealloc? I don't see how that can trigger a race condition or call anyone else's dealloc.

You may have a valid point but I don't grasp it.

Think delegates, or observers. There is a race condition between calling the delegate and deregistration of the delegate. Once an object's dealloc method has been called, you must not resurrect it, but there is a race between the execution of -dealloc, the de-registration of the delegate, and the dispatch of messages to the delegate.

So you're setting threadedObject.delegate = nil in your delegate object's dealloc, but the threadedObject is sending subsequent messages to your delegate? The doesn't sounds like a retain-release problem. Wouldn't the same thing happen when setting threadedObject.delegate=foo? Messages could still get send to the old delegate if you haven't done your synchronization right.

Missing the forest for the trees. The problem is that the old delegate will be invalidated before it deregisters itself, because it will not deregister itself until it is invalid (during -dealloc)

Reply on news.ycombinator.com