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.
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
substringWithRange:. I would assume he meant messaging on a higher
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
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
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
If all methods were only to accept the most basic objects type
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
- (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
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
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.