Structure and Interpretation of Computer Programmers

I make it easier and faster for you to write high-quality software.

Monday, February 9, 2009

When techs collide

If you’ve ever seen the film Ghostbusters, you’ll know that each of the proton packs was, on its own, very powerful and capable of performing its function. Combine two, by crossing the streams, and rather than something twice as powerful you have a potentially Zuul-beating, potentially universe-destroying chaotic mess on your hands.

Such a combination I found today, when I mixed a little bit of Distributed Objects with a soupçon of Cocoa Bindings to create, um, Distributed Bindings (calling it Cocoa Objects would just be rude).

It’s actually just as simple as you think it will be, so there’s no point in any sample code. You can basically use the answer to the FAQ question on DO. Once you’ve got the proxy object in the client, use it as the observable controller in -bind:toObject:withKeyPath:options:. And that’s it!

Well, not quite it. You’ll notice that things are a wee bit crashy, which is why this is somewhat like crossing the streams. Both Bindings and DO use the Proxy pattern to achieve their magic, but because the two systems have no special knowledge of each other the proxy connections are not kept in sync. If your server object mutates after the DO connection disappears, then it tries to send a KVO notification to an object that’s no longer there…boom. Having a client-server system where the client can crash the server is of, well, dubious utility. There are some things that you could do to mitigate this, for instance looking for NSConnectionDidDieNotification (in the server) or opening a heartbeat RPC for the client to “check in” with the server. These fixes will work perfectly, if the vended object is updated predictably enough that you can reliably take care of broken connections between KVO notifications. Without that you’re SoL, as the server won’t reliably get a DO exception – more often than not it’ll segfault. But while this may be unstable, it still is damned cool.

posted by Graham Lee at 21:25  

Monday, December 22, 2008

Cocoa Memory Management

It becomes evident, thanks to the mass centralisation of the neverending september effect that is stackoverflow, that despite the large number of electrons expended on documenting the retain/release/autorelease reference counting mechanism for managing memory in Cocoa, Cocoa Touch, UIKit, AppKit, Foundation, GNUstep, Cocotron and Objective-C code, very few people are reading that. My purpose in this post is not to re-state anything which has already been said. My purpose is to aggregate information I’ve found on the topic of managing memory in Cocoa, so I can quote this post in answers to questions like these.

In fact, I’ve already answered this question myself, as How does reference counting work? As mentioned in the FAQ, I actually answered the question “how do I manage object lifecycles in (Cocoa|GNUstep|Cocotron)”? It’s actually a very violently distilled discussion, so it’s definitely worth checking out the references (sorry) below.

Apple have a very good, and complete, Memory Management Programming Guide for Cocoa. They also provide a Garbage Collection Programming Guide; remember that Objective-C garbage collection is opt-in on 10.5 and above (and unavailable on iPhone OS or earlier versions of Mac OS X). GNUsteppers reading along should remember that the garbage collector available with the GNU objc runtime is entirely unlike the collector documented in Apple’s guide. GNUstep documentation contains a similar guide to memory management, as well as going into more depth about memory allocation and zones. Apple will also tell you how objects in NIBs are managed.

The article which gave me my personal eureka moment was Hold Me, Use Me, Free Me by Don Yacktman. Stepwise has another article, very simple rules for memory management in Cocoa by mmalc, which is a good introduction though with one caveat. While the table of memory management methods at the top of the article are indeed accurate, they might give you the impression that keeping track of the retain count is what you’re supposed to be doing. It’s not :). What you’re supposed to be doing is balancing your own use of the methods for any given object, as described in rules 1 and 2 of “Retention Count rules” just below that table.

James Duncan Davidson’s book “Learning Cocoa with Objective-C” has not been updated in donkey’s years, but its section on memory management is quite good, especially the diagrams and the “rules of thumb” summary. Luckily, that section on memory management is the free sample on O’Reilly’s website.

If reading the theoretical stuff is all a bit too dry, the Mac Developer Network have a rather comprehensive memory management training video which is $9.99 for non-MDN members and free for paid-up members.

Finally, Chris Hanson has written a good article on interactions between Cocoa memory management and objc-exceptions; if you’re using exceptions this is a good discussion of the caveats you might meet.

posted by Graham Lee at 13:34  

Sunday, December 21, 2008

better security, not always more security

Today’s investigative investigations have taken me to the land of Distributed Objects, that somewhat famous implementation of the Proxy pattern used for intra-process, inter-process and inter-machine communication in Cocoa. Well, by people who measure whether it’s a performance hog, rather than those who quote it; as a hint, it was indeed a significant overhead when your CPU was a 25MHz 68030 and your network link a 10BASE-2 coaxial wire. These days we can spend around those problems freely.

Specifically, I wondered whether I should add discussion of the authentication capabilities in PDO to the FAQ entry. Not that it’s frequently asked – indeed, it’s a NAQ – but because getting mentions of security into a Usenet FAQ is likely to cause newbies to be thinking about security, which is possibly a good thing (for the world, not so much my uniquely employable attributes). But I decided no, though the subject is interesting, it’s not because of the technicality, but the philosophy.

Distributed Objects works by sending NSPortMessage messages over NSConnection connections. The connections and message-passing bumph are peer-to-peer, but DO adds some client-server distinction by having servers register their vended connections with name servers and clients look up the interesting vendors in said name servers. By default, anything goes; all connections are honoured and all clients serviced. There are two security features (both implemented as delegate methods) baked into DO, though. The most interesting of the two is the authentication.

The reason that the authentication feature is interesting is that it’s implemented in such a way as to make non-security-conscious developers question the security. The end sending the NSPortMessage includes some data based on the constituent parts of the message, and the end receiving the message decides whether to accept it based on knowledge of the constituents and of the data. On the face of it, this looks like shared-secret encryption, with the shared secret being the algorithm used to hash the port message. It also appears to have added no security at all, because the message is still sent in plain text. In fact, what this gives us is more subtle.

All that we know is that given the source information and the sender’s authentication data, the receiver gets to decide whether to accept the sender’s message. We don’t necessarily know the way that the receiver gets to that decision. Perhaps it hashes the information using the same algorithm as the sender. Perhaps it always returns YES. Perhaps it always expects the authentication data to be 42. On the other hand, perhaps it knows the public key of the sender, and the authentication data is a signature derived from the content and the sender’s private key. Or perhaps the “authentication data” isn’t used at all, but the source material gives the server a chance to filter malicious requests.

Now all of that is very interesting. We’ve gone from a system which looked to be based on a shared secret, to one which appears to be based on whichever authentication approach we decide is appropriate for the task at hand. Given a presumed-safe inter-process link, we don’t need to be as heavyweight about security as to require PKI; whereas if the authentication were provided by a secure tunnel such as DO-over-SSL, we’d have no choice but to accept the cost of the PKI infrastructure. Given the expectation of a safe server talking to hostile clients, the server (or, with some amount of custom codery, a DO proxy server) can even sanitise or reject malicious messages. Or it could both filter requests based on authentication and on content. The DO authentication mechanism has baked in absolutely zero policy about how authentication should proceed, by letting us answer the simple question: should this message be processed? Yes or no? Choose an approach to answering this question based not on what you currently believe could never be circumvented, but on what you currently believe is sufficient for the environment in which your DO processes will live. If a shared secret is sufficient and adds little overhead, then do that, rather than 4096-bit asymmetric encryption.

By the way, the second security feature in DO is the ability to drop a connection when it’s requested. This allows a DO server to survive a DoS, even from a concerted multitude of otherwise permissible clients.

posted by Graham Lee at 03:45  

Saturday, October 4, 2008

Properties about a year on

Leopard has now been out for nearly a year, which means that (publicly) we’ve had Objective-C 2.0 for the same amount of time. At the release many developers were champing at the bit to talk about the new language capabilities[], including properties. There were arguments on both sides of the divide, and even a little bit of discussion. But now that we’ve been using these things for a while, and because I’m bored awake grouchy vocal opinionated, let’s have a look back at what they’ve given us.

There is a broken abstraction in traditional Objective-C, which is the accessor-method-as-property-declaration. Essentially an object can give you two things; work (i.e. it can do stuff) and state information (i.e. it can say stuff about itself and let you change it). In traditional object-oriented languages, because ‘saying’ and ‘changing’ are verbs which can be ‘done’, the two have both been expressed using the same method (heh) as the expression of work. This is not the case in much object-oriented design, for instance in UML a class always has separate “attributes” and “operations”.

Properties fix up this abstraction by giving us orthogonal ways to express the two concepts. Work is done in methods; state is got/changed in properties. Now it may be that the state information is actually backed by a method (although it may bang on the ivar directly; more below), but we don’t need to know that any more than we need to know in the interface that a property is synthesized or dynamic. All we do need to know is that it is there for us to use, and has certain attributes such as being read-only.

The “on more below” bit is that discussions of KVC-like mechanisms – such as KVC :-) – often involve someone pointing out that they break encapsulation, because it’s possible to access an @private ivar with no accessors by retrieving it by key. That’s really thinking about the design of a class in terms of the way it’s executed rather than its interface contract with the developer, because the @private ought to tell the developer not to touch that particular ivar. Properties neither help nor hinder breakage from the execution side, but from the design side they do provide a stronger distinction between “properties I’m telling you about in the interface” and “things you shouldn’t touch”. Now we can all get back to using the class’s interface to observe how to use it, and that C struct bit at the top to observe how to extend it, as nature intended. It’s both a blessing and a curse that Objective-C allows things to appear in source files which don’t make it into the executable code, but that doesn’t stop such information being useful to the developer in the same way that code comments can be read but not executed.

One of the popular complaints about ObjC properties is the syntax for referring to them in methods (OK, or indeed in functions), where it is argued that myObject.someProperty = 4; doesn’t readily tell you whether myObject is an ObjC object, a C struct or a C union. That seems to be at worst a straw man argument to me, and at best a hypothetical issue; in well-designed software it will be rare to mix code at various levels of abstraction except in limited circumstances such as adapter classes. Besides, if the code has been written such that it can be inspected or reviewed (i.e. to some agreed style and standard) and the reviewer is paying attention then it will be easy to distinguish use of the various types. At some conceptual level the C . and Objective-C . operator are doing the same thing anyway; they’re both saying “this attribute of that thing”.

[]The fact that I have stopped using the word ‘feature’ in many contexts is an entire blog post and a few therapy sessions in itself.

posted by Graham Lee at 06:20  

Sunday, September 28, 2008

MacDev 2009!

It’s a long way off, but now is a good time to start thinking about the MacDev ’09 conference, organised by the inimitable Scotty of the Mac Developer Network. This looks like being Europe’s closest answer to WWDC, but without all those annoying “we call this Interface Builder, and we call this Xcode” sessions. Oh, and a certain Sophist Mac engineer software will be talking about building a secure Cocoa application.

posted by Graham Lee at 20:27  

Monday, September 1, 2008

A better bit o’ twitter than the bitter twitter Tommy Titter bought

Just because everyone these days writes a Twitter client:

This was actually a quick hack project to make up for the fact that I missed CocoaHeads tonight (due to a combination of an uninteresting phone call, and a decision to recover from the phone call by using the rest of my petrol tank). Really just an excuse to play with some APIs (the tweets are grabbed by the controller using NSURLConnection, then some NSXML/XPath extracts the useful information (or not, it is Twitter after all) and puts it into the model), there are many things which need to happen before this is at all a useful Twitter client; the ability to write back, nicer formatting are just the starters. Shiny Core Animation twitting ought to happen.

Still, not bad for two hours I think.

posted by Graham Lee at 22:26  

Tuesday, June 24, 2008

Objective-C NAQs

Never-Asked Questions :-)

In Code Complete 2 §6.5, Steve McConnell presents a list of class-related design issues that "vary significantly depending on the language". So why don’t we look at them for Objective-C? Especially as I can’t find anyone else who’s done so based on a couple of Google searches… N.B. as ever, I’m really considering Cocoa + Objective-C here, as the language itself doesn’t provide enough policy for many of the issues to have an answer (only method resolution and the existence of isa are defined by the runtime and the compiler – ignoring details like static string instances, @protocol and so on).

Behaviour of overridden constructors and destructors in an inheritance tree. Constructors are simple. If you can initialise an object, return it. If you can’t, return nil. The -[NSObject init] method is documented as simply returning self.

For destructors, we have to split the discussion into twain; half for garbage collection and half for not. In the world of the Apple GC, destruction is best done automatically, but if you need to do any explicit cleanup then your object implements -finalize. The two rules are that you don’t know whether other objects have already been finalized or not, and that you must not resurrect your object. In the world of non-GC, an object is sent -dealloc when it has been released enough times not to stick around. The object should then free any memory claimed during its lifetime, and finally call [super dealloc]. Note that this means objects which use the voodoo cohesion of “OK, I’ll clean up all my resources in -dealloc” probably aren’t going to work too well if the garbage collection switch is flipped.

Behaviour of constructors and destructors under exception-handling conditions. Exceptions are a rarity in Cocoa code (we didn’t have language-level exceptions for the first decade, and then there was a feeling that they’re too expensive; C++ programmers like the Leopard 64-bit runtime because ObjC exceptions and C++ exceptions are compatible but that’s not the case in the NeXT runtime) but obviously a constructor is an atomic operation. You can either initialise an object or you can’t; there’s no half-object. Therefore if an -init… method catches, the thing to do is unwind the initialisation and return nil. The only thing I can think to say for having exceptions around destruction time is “don’t”, but maybe a commenter will have better ideas.

Importance of default constructors. All classes implement -init, except those that don’t ;-). Usually if there’s a parameterised initialiser (-initWithFoo:) then that will be the designated initialiser, and -init will just return [self initWithFoo: someReasonableDefaultValueForFoo];. If there’s no reasonable default, then there’s no -init. And sometimes you just shouldn’t use -init, for instance NSNull or NSWorkspace.

Time at which a destructor or finalizer is called. See How does reference counting work? for a discussion of when objects get dealloced. In the garbage-collected world, an object will be finalized at some time after it is no longer reachable in the object graph. When that is exactly really depends on the implementation of the collector and shouldn’t be relied on. Temporal cohesion (“B happens after A, therefore A has been done before B”) is usually bad.

Wisdom of overriding the language’s built-in operators, including assignment and equality. This is such a brain-damaged idea that the language doesn’t even let you do it.

How memory is handled as objects are created and destroyed or as they are declared and go out of scope. How does reference counting work? How do I start using the garbage collector?

posted by Graham Lee at 22:33  

Wednesday, June 11, 2008

WWDC aside

None of Perl, Cocoa or some weird XML toolkit came up with the “simple things simple, complex things possible” quote.

posted by Graham Lee at 21:40  

Tuesday, June 10, 2008

ObjC FAQ update

Added a question about the ObjC 2.0 garbage collector. Sorry it’s been so long in coming! I’ll try and add a few more ObjC 2.0 questions over the coming days.

posted by Graham Lee at 15:24  

Monday, June 9, 2008

WWDC part 0

well, here it is, the pre-WWDC “I’m jetlagged so you have to put up with my wittering” post. I’m just waiting for a softwareupdate to finish so that I can go out with my camera, taking some early-morning pictures before heading off to stand in line for the Stevenote. I was out for beers with Ian and Neil last night, we’d all heard rumours of a 5 a.m. start to the queue. On the two previous occasions that I’ve been, 9 a.m. has been sufficient; but with the sellout nature of the event it’s likely that the room will fill up rather quickly so we’ve compromised on a 7 a.m. start. Actually, forget the 5 a.m. nonsense, there’s a line of overnight campers – I can’t decide whether they’re deliberately trying to re-enact a Joy of Tech cartoon, or actually have nothing to do with their lives.

posted by Graham Lee at 12:42  
« Previous PageNext Page »

Powered by WordPress