Nat!

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:

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: