Loosely connected thoughts about messaging and types in mulle-objc

One alternative Objective-C implementation was JXobjC, which was based on David Stes’ Portable Object Compiler. I found this project quite inspirational. Not necessarily because I thought this was what I wanted, but it featured this “marxist” duck and it’s proclamation:

And in The Philosophy of the Programming Language Objective-C (JX) it quoted Alan Kay:

Objects [are] like biological cells, or individual computers on a network, able to communicate with messages.

Message abstraction

Having never met Alan Kay or read any of his missives, I would still assume, that when he’s talking about “cells communicating with messages”, he’s not talking about objectAtIndex: and count or substringWithRange:. I would assume he meant messaging on a higher abstraction level. A good (?) analogy for a higher abstraction level might be the Unix device system, where you have devices of varying types and capabilities, all communicating with a common subset of commands open, read, write, close. But you aren’t asking your SSD on PCI#2 to fetch sector 100 or your keyboard to read the next keypress.

This leads immediately to questions as to what is the right granularity of methods and functions ? But this isn’t the topic of this particular little entry, though I want to revisit this. Instead lets focus on a technical aspect of “communicating with messages” and how types interfere.

Selectors and Types and their problems

Terminology

A function that can be messaged via an object and a selector is called a method. The selector is equivalent to the name of the method without types. The process of looking up and calling this method via the selector and the object is called messaging (the object). The most generic object type is id.

If all methods were only to accept the most basic objects type id as arguments and only to return an object as id as the return value, a selector would be fully self-describing and without the possibility for conflict. The selector indicates the number of objects passed with ‘:’ (ignoring or interdicting variable arguments) and the types are always objects: - (id) foo:(id) a bar:(id) bar;

A further typing by object classes or protocols: - (NSNumber *) foo:(NSString *) a bar:(NSArray *) bar; will add the possibility for conflict as another class may declare: - (NSData *) foo:(NSDictionary *) a bar:(NSString *) bar;. Yet this does not impede the ability to message the arguments or the return value.

Alas this is not the case in Objective-C nowadays, where you can specify any C type as argument and return value. You could pass char * or float, but messaging those will lead to undefined and unwanted behaviour (-> crashes). It is the current state of affairs though and it has to be supported by mulle-objc.

Even worse, in an Objective-C program, you can define methods of the same name with different types. For example in AppKit there is a method - (BOOL) load on NSBundle and there is a + (void) load that is part of the Objective-C runtime. Two selectors with the same name but different return value types. Clearly that is not what was intended by “messaging”.

The mulle-objc selector type warning

mulle-objc will not forbid selectors with varying types, but you will get a runtime warning:

mulle_objc_universe 0x1100bf570 warning: varying types "v16@0:8" and "i16@0:8" for method "load"

While this doesn’t solve any larger problem, it is a small step in the direction of a more general kind of messaging, than that is currently being practiced in Objective-C.