Objectionable-C

[joshua0]

- (IBAction) loadFile : (id) sender {
	NSImage *im;
	
	[model loadData:"/Users/joshua/projects/dvbt/dvbt.mixed.raw"];
	[nsamples setIntValue:[model getSampleCount]];
	
	im = [[NSImage alloc] initWithSize: NSMakeSize(64, 64)];
	[im lockFocus];
	[[NSColor redColor] set];
	NSRectFill(NSMakeRect(16, 16, 16, 16));
	[im unlockFocus];
	
	[iview setImage: im];
}

Seriously, what the fuck is this shit?

Comments

[zetorux.livejournal.com]

Yeah that looks like C to me

[demarko (from livejournal.com)]

what about it specifically?

[joshua0]

There are a few things in particular that I have problems with. Objectionable-C isn't actually that bad (mostly, I just like calling it Objectionable-C), but:

• The syntax. Oh my god, the syntax. It's a function call (well, if you subscribe to the Objectionable-C way of thinking, it's actually a message call, but it doesn't have any of the nice serialized behavior that a message call has... it's surely not IPC safe...), so why are we using this ridiculous bracket syntax? Wasn't the existing function pointer syntax good enough for you???


• Function calls are kind of wrong. One parameter, OK. Two parameters, less OK.


• Function calls (which are still called 'message calls' or some such) don't actually look something up in a vtable. (This is OK, sort of; vtables are kind of nasty.) My understanding, though, is that they do something worse -- they look up a string (in the case above, loadData) in a hash table, and hope it exists to send a packet out to it. What they'd like you to believe in your mental model is that it sends you a response packet, but what actually happens is the same as anywhere else -- it loads some bullshit into %eax and you walk away happy.


• Observe that the type (in the wonky syntax) for sender is id. This, for those not initiated into the Cult of Objectionable-C, is kind of like void, except it's the object version, and instead of being able to do nothing on it, you can do everything on it. Remember how we looked strings up in a hash table (or the moral equivalent) to call things before? What this means, as I understand it, is that Objectionable-C is duck-typed -- all of the hard work of typechecking functions, for naught! (This more or less directly links to why argument passing to "messages" in Objectionable-C is insane.)


• Now getting to specific complaints: Come on, guys. We had this beautiful little object system going here, and now we're going to introduce world state (in particular, which image is locked), and have only one image mutable at a time using the standard NSRectFill call? Really? I could swear it's 2009...


• NSRectFill looks... a little out of place. Shouldn't it be something like [NSDrawerizer RectFill: (NSMakeRect (16, 16, 16, 16))] or some such? Seeing an unencapsulated function when even redColor is encapsulated seems a little... sad...

Now, I realize that some of this is because of legacy issues. Back in the bad old days, everyone and their grandma called NSRectFill, and now it just has to gosh darn stay. In truth, some of these complaints are mostly stemmed from "it's different from C++, which is the object system I'm familiar with". I have to commend Apple for really doing a good job linking in things from the Interface Builder -- in particular, [nsamples setIntValue: [model getSampleCount]]; is quite pretty, aside from the strange Objectionable-C syntax.

This block of code is somewhat demonstrative of a point that I found myself making earlier this evening -- with every windowing toolkit eventually comes its own language. GTK+ has Vala (the natural evolution of the GTK+ object system); wxWidgets has C++ (which, although not its own, has the same roots; the natural evolution of a pile of steaming shit); and Cocoa has Objectionable-C (the natural evolution of Smalltalk except with more systemsy).

Uh, ... yeah this is longer than I intended it to be. I'm going to sleep.

[rincebrain.livejournal.com]

But but Objectionable C wanted it to be visually clear where the Objectionable parts started and C ended!