My method was to use C structures for classes, where methods are function pointers as members of the structure; instance variables are to be encapsulated (that is, only touched through accessors and mutators). For every class it is necessary to have a constructor and a destructor. Finally, instances of these classes should be referred to by pointers, like in Objective-C.

I decided to implement a rudimentary string class called PString:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

typedef struct pstring_t {
  /*
   instance variables
   */
  char * chars;

  /*
   instance methods
   */
  int (* length)(struct pstring_t *);
  char (* characterAtIndex)(struct pstring_t *, int);
  char * (* value)(struct pstring_t *);
  void (* setValue)(struct pstring_t *, char *);
  void (* destroy)(struct pstring_t *);
} PString;

The class PString has one instance variable, a char array called chars. It has five methods: length, characterAtIndex, value, setValue, and destroy. Next, the functions that implement these methods, as well as a constructor, must be declared:

1
2
3
4
5
6

PString * initializePString();
int length(PString * self);
char characterAtIndex(PString * self, int i);
char * value (PString * self);
void setValue(PString * self, char * chars);
void destroy(PString * self);

The first function returns a pointer to an initialized PString. initializePString() allocates memory for the PString and its instance variables, and sets the function pointer members of its structure to the functions declared above:

1
2
3
4
5
6
7
8
9
10
11

PString * initializePString() {
  PString *str=(PString*)malloc(sizeof(PString));
  str->chars = (char *)malloc(sizeof(char) * 1);
  str->chars[0] = '';
  str->length = &length;
  str->characterAtIndex = &characterAtIndex;
  str->value = &value;
  str->setValue = &setValue;
  str->destroy = &destroy;
  return str;
}

Finally, the methods of PString are implemented in the following functions:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

int length(PString * self) {
  return strlen(self->chars);
}

char characterAtIndex(PString * self, int i) {
  return self->chars[i];
}

char * value(PString * self) {
  return self->chars;
}

void setValue(PString * self, char * chars) {
  free(self->chars);
  self->chars = (char *)malloc(sizeof(char) * (strlen(chars) + 1));
  strcpy(self->chars, chars);
}

void destroy(PString * self) {
  free(self->chars);
  free(self);
}

Each method takes a pointer to a PString called self. In object-oriented languages built on top of C, methods take a hidden parameter that references their owner. Right now, using these methods is no better than having normal functions, because you have to enter the self parameter:

1
2
3
4

PString * str = initializePString();
str.setValue(str, "a value");
printf("string: %s", str.value(str));
str.destroy(str);

In order to work around this, I created two #define macros: one for methods that take no parameters other than self, and another for those that take one or more:

1
2

#define $(obj,method) obj->method(obj)
#define $(obj,method,args) obj->method(obj,args)

Now, the code above can be rewritten as:

1
2
3
4

PString *str = initializePString();
$(str, setValue, "a value");
printf("string: %s", $(str, value));
$(str, destroy);

It isn’t the prettiest syntax in the world, but it works. You can clone this entire project from Github.

This time, instead of implementing a String class, we are going to build a relatively useless Person structure, which can be manipulated using normal C functions. First, we will declare the structure and function prototypes in our header file:

1
2
3
4
5
6
7
8
9
10

typedef struct person_t {
  char * firstName;
  char * lastName;
  int age;
} Person;

char * person_getFullName(char ** dest, Person p);
Person * person_addToAge(Person * p, int years);
Person * person_revertToInfancy(Person * p);
void person_sayHello(Person p);

Now, the helper functions can be implemented:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

char * person_getFullName(char ** dest, Person p) {
  *dest = (char *)malloc((strlen(p.firstName) + strlen(p.lastName) + 1) * sizeof(char));

  strcpy(*dest, p.firstName);
  strcat(*dest, " ");
  strcat(*dest, p.lastName);

  return *dest;
}

Person * person_addToAge(Person * p, int years) {
  p->age += years;
  return p;
}

Person * person_revertToInfancy(Person *p) {
  p->age = 0;
  return p;
}

void person_sayHello(Person p) {
  char * fullName;
  printf("Hi! I'm %s! Hello World!\n", person_getFullName(&fullName, p));
  free(fullName);
}

Notice that functions that manipulate a Person structure take a pointer to that structure as an argument (this is sort of like self or this in object-oriented programming). Functions that merely use data from a Person structure don’t use a pointer for an argument, because it is unnecessary; it would work if they did (of course, p.member would have to change to p->member), but it doesn’t make a lot of sense to do it that way.

Now, these functions can be tested as follows:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

Person jon;
jon.firstName = "Jonathan";
jon.lastName = "Sterling";
jon.age = 17;

char * fullName;
person_getFullName(&fullName, jon);

printf("Jon’s full name: %s\n", fullName);
free(fullName);

printf("Jon’s original age: %i\n", jon.age);
printf("adding 30 years…\n");
person_addToAge(&jon, 30);
printf("Jon’s new age: %i\n", jon.age);

printf("reverting to infancy…\n");
person_revertToInfancy(&jon);
printf("Jon’s new age: %i\n", jon.age);

person_sayHello(jon);

The output of that is as follows:

Jon’s full name: Jonathan Sterling
Jon’s original age: 17
adding 30 years…
Jon’s new age: 47
reverting to infancy…
Jon’s new age: 0
Hi! I’m Jonathan Sterling! Hello World!

I hope that this tutorial has been educational. As always, you can grab the source to this project on Github.

What I really wanted was a version of Smalltalk that used the same object modal as Objective-C, like Pragmatic Smalltalk of Etoilé, or even MacRuby on Mac OS. Most of all, I wanted it to treat me like an adult: I don’t need a class browser, thank you, I’m more comfortable working with plain-old files. The persistent image construct in Smalltalk really makes me uncomfortable.

Eventually, I found F-Script, a scripting environment for Mac OS based on Smalltalk. It is not really meant for developing full applications, but with a little work, I was able to make this work.

First, we will need a bare-bones Xcode project for an Objective-C application with a XIB. Remove all of the instance variables, outlets and properties from your application delegate. Before we go any further, we’ll need to create class in F-Script, which we will call WindowController. Create a new file WindowController.st in your Resources group. You may consider using TextMate for editing, because there are is an F-Script bundle you can use, whereas Xcode does not support highlighting of Smalltalk.

Writing the Smalltalk component

We need to define a class and its instance variables (I apologize for the mis-coloring of some code; my highlighter isn’t built for F-Script’s dialect of Smalltalk):

Note that comments are made by putting double-quotes around text.

Now, we can start writing the instance methods for this class. As always, we start with an initializer:

It doesn’t appear that F-Script supports making your own symbolic constants like Ruby, so I used instance variables set in -init instead.

Next, we need to have it create and present our window. The following code will show you how some plain C constructs used in Objective-C (like Cocoa graphics structs, &c.) map into F-Script:

At the end of -loadWindow we have a call to windowDidLoad, which is implemented as follows:

There were a few calls in -windowDidLoad to methods we need to implement. These will be a good example of the block-based control structures of Smalltalk, where -ifTrue, -ifFalse is a method:

Finally, we can’t forget to end our class: }..

Some notes on syntax

To declare local variables, we surround them in bars: | localVar1 localVar2 |. Note that like in Ruby, mathematical operators are really messages sent to the objects behind them.

Statements are ended with a period (.), but the semicolon (;) does something entirely different. In Objective-C, we might do the following:

in a Smalltalk variant, we can do this instead:

Linking WindowController with our application.

This is the last and most important part of this tutorial. We cannot use our Smalltalk code without somehow loading it from the Objective-C portion of our application.

F-Script includes a framework that facilitates executing blocks of F-Script code, and that is how we will combine our Smalltalk WindowController class with our Cocoa application. First, add FScript.framework to your Xcode project. Then, make sure your AppDelegate.h file imports it.

Now, in -applicationDidFinishLaunching:, you need to load our code into an FSBlock:

Now, you can create an instance of WindowController and use it (note that you must type your instance id, because this sort of hackery will not allow specific typing):

The beautiful thing here is that we called several methods (+alloc, -init, and -loadWindow) in Objective-C from a class created in Smalltalk. All this should make a window pop up that functions as we would expect it to:

Making it even easier!

Of course, if you have many Smalltalk classes to load, all this loading code can be quite a pain; naturally, I wrote a #define directive for it:

Caveats

Unless you somehow encode your Smalltalk files and then decode them at runtime, the code for the Smalltalk portion of your application will be available to any user smart enough to open your application package. Also, if you use the #define I gave you above, you must make each .st file have only one class, and have that class’s name match the name of the file.

Conclusion

I hope that this information and code brings joy not only to my fellow Smalltalk enthusiasts, but also to those Objective-C programmers who want an insight into the origins of their language.

Indeed, if something that is terrible is good enough for me, there follow two consequential facts: that I have bad taste, and that I have shirked the duty of shaping the marketplace through my decisions as a consumer. The thing about Capitalism is that it only works when people care enough about the shit they are buying to demand perfection: if perfection is something that is displaced by raw practicality, we have damaged the marketplace and our chances of having good things.

Good enough to a paying customer should always mean that the product is functional, and beautiful (not only with respect to visual design, but also data abstraction), and crafted with love. On the contrary, the word you are looking for when you try to justify the purchase of a substandard product is “best” or “better”: no stipulations are made as to the upper limits of its actual quality. Hence, when someone boasts that his product is the best of its kind, a little red flag needs to go up: unless you are an early-adopter (we’ll leave that for another essay), run away fast. Because the product certainly isn’t yet good enough, or a comparison to similar products would have been unnecessary.

Don’t let poor design make you its bitch, just because it is hard to find an alternative. If there were no systems like Mac OS and iOS, I would be composing this essay on a typewriter: life is too short for you to be given the run-around by other people’s bad ideas. And typewriters still work just fine.

You are a factory owner, and as before you own a set of processing machines. Processing machines are just a metaphor for functions; they accept some input and produce some output. Your goal is to combine these processing machines so that they can perform richer, and more complicated tasks. Monads allow you to combine these machines in a pipeline. Arrows allow you to combine them in more interesting ways. The result of this is that you can perform certain tasks in a less complicated and more efficient manner. — “Haskell: Understanding Arrows”

I started to black out, watching my notepad fall from my fingers as I lost consciousness. I was standing in a pitch-dark holodeck, counting the yellow stripes on the floors and walls. He could not see me, but I spied a man in a white lab-coat wearing a pince-nez, sporting a smart mustache; a few feet away lay a fat man in sweats on a red couch. I laughed out loud (audibly only to myself), for each time the latter man moved his hand, one of his other limbs would involuntarily twitch, shiver or kick.

“Your problem, Herr C.,” I heard the first gentleman say as he paced back and forth, “is that you have no control over the side-effects of your movements.” The fat man whimpered. “Likewise, your motor control is problematic: for instance, when tossing a ball between both hands, you often try to catch before you have finished throwing.”

The fat man shook his head. “But,” he started with a shaky voice, “I’m more flexible than you are. I can do lots of things.”

The gentleman wagged his finger at his patient: “Tut tut, your flexibility is a function of your impurity and inability to think properly; indeed, you would ingest a rock if someone told you it were an apple wrapped in gray cloth. No, I see no hope for you.” He paused.

“In fact, let us try an experiment. You are to make a list of the first one hundred odd numbers, and then recite them; I will do likewise. Perhaps after you see my method, you will realize how hopeless you really are.”

I walked toward Herr C. and watched over his shoulder; he noticed neither my presence nor his own putrid stench. This is what he wrote:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

#include <stdio.h>

int main () {
  size_t n = 100;
  int odds[n];

  size_t i;
  for(i = 0; i < n; ++i) {
    odds[i] = 2 * i + 1;
  }

  size_t j;
  for(j = 0; j < n; ++j) {
    printf("%s%i%s", (j != 0 ? "," : "["), odds[j], (j == (n-1) ? "]" : ""));
  }

  return 0;
}

The moment he had finished writing, he shouted the following triumphantly:

[1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31,33,35,37,39,41,43,45,47,49,51,53,55,
 57,59,61,63,65,67,69,71,73,75,77,79,81,83,85,87,89,91,93,95,97,99,101,103,105,
 107,109,111,113,115,117,119,121,123,125,127,129,131,133,135,137,139,141,143,
 145,147,149,151,153,155,157,159,161,163,165,167,169,171,173,175,177,179,181,
 183,185,187,189,191,193,195,197,199].

“See? I got it right!”

“Well done, Herr C.,” replied the man in the pince-nez. “But perhaps you will want to see my solution.” He handed the fat man his notepad.

main = print [2*i + 1 | i <- [0..99]]

Herr C. began to cry; as I watched him, I pitied him. Indeed, I hoped that when I reached his age, my life would not be as disappointing. Despite the emotional state of his patient, the Psychologist was relentless: “That was diverting, was it not? Now we shall each modify our solutions to additionally return the sum of the first one hundred odd numbers. Proceed.”

The fat man rubbed his paper with his sleeve, only smearing his writing with tears. He began:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

#include <stdio.h>

int main () {
  size_t n = 100;
  int odds[n];

  size_t i;
  for(i = 0; i < n; ++i) {
    odds[i] = 2 * i + 1;
  }

  size_t j;
  int s = 0;
  for(j = 0; j < n; ++j) {
    s = s + odds[j];
    printf("%s%i%s", (j != 0 ? "," : "["), odds[j], (j == (n-1) ? "]" : ""));
  }

  printf("\nsum: %i", s);

  return 0;
}

But his efforts were in vain, for though he came up with the right answer, the Psychologist’s solution was far more elegant:

1
2

main = print odds >> print ("sum: " ++ (show . sum) odds)
          where odds = [2*i + 1 | i <- [0..99]]

With that, the fat man evaporated. As I gasped, the man in the white lab-coat turned toward me: “You probably imagined that I could not see you; the fact that I did not evaluate you until now is unrelated to the time at which I noticed you. You have much to learn, young man.”

Here’s to the crazy ones. The misfits. The rebels. The troublemakers. The round pegs in the square hole. The ones who see things differently. They’re not fond of rules. And they have no respect for the status quo. You can quote them, disagree with them, glorify or vilify them. About the only thing you can’t do is ignore them. Because they change things. They push the human race forward. And while some may see them as the crazy ones, we see genius. Because the people who are crazy enough to think they can change the world, are the ones who do. — Apple Inc.

By the way, what have you done that’s so great? Do you create anything, or just criticize others’ work and belittle their motivations? — Steve Jobs

I know people. Some of them are even reading this. You know who you are. The ones who sighed in relief when it became cool to be a geek, when the International Baccalaureate became a source of pride and mutual camaraderie. You’re one of the new generation of movers, shakers and future-makers; but what’s this? You’re hiding?

Where is it that you really belong? You know you don’t belong here, and your worst fear is that everyone else knows this too. Everyone around you is comfortable, confident and excited for the future, and you’re living a dream. Someone else’s dream, one you can only watch others fulfill. As the years go by, the expectations of a high-schooler are proved to be justified, just not by you. By the people you used to hang out with, row boats with, study with.

Where is he? He’s moving and shaking simultaneously, so hard he can barely hear you. Every once in a while, he passes through your life; “You were going to be a scientist, right? That’s so cool,” he says. You don’t have the courage to tell him that you ended up becoming a paralegal, or a nurse’s assistant in Just Nine Months™, that your grand dreams for the future had to be put aside for whatever reason: you had a kid, you didn’t think you were good enough, you couldn’t afford the future.

Then he rides off in his motorcycle that he bought “because he felt like it”. Part of you wants to shave his trendy stubble with a chain-saw, but the other part wants to ask him how he got where he is, what you did wrong fifteen years ago. But as always, you don’t. You don’t ask him anything, you just say, “Man, it was so cool to see you again! We should get the old gang back together some day, talk about old times…”

“Yeah, man, that would be really cool. Well, I’ve gotta run. Diamonds wait for no man.” There is opportunity for the taking in Africa; you just have to see it! And you know you won’t see him again for another few years (unless stalking him on the Internet counts).

Like I said, you know who you are. Your problem is that you stole another man’s path, and were surprised when he took it back; I carved out my own. You don’t need to hide in a throng of geeks to be well-liked.

Short-attention-span-mercy: If you want to see what I have done, just check out my Github repository. But be sure to scroll down to the end of the article to see my neat-o expressive array and dictionary syntax.

FunctionKit is still in the early stages, and may change a lot in the future (so what you see in this post may not stay relevant). But I’d like to show you some of the cool things that are possible with it. First of all, FunctionKit depends upon Objective-C++ because it uses templates as well as operator overloading. Instead of giving a boring narrative of the hows and whys, I’m just going to show a few examples.

Functions

For reasons that will become clear in the Functor section of this article, functions are implemented as blocks wrapped in C++ structs that overload the operator(). The following returns a function: fk::f(^(id val) { return @"hello!"; }). Note that all functions are of one argument only; I find that single-arity functions are easier to work with, and lend themselves better to functional programming. I do realize, however, that without proper function currying, this is a weakness.

Because we are using a C++ struct, functions can also be composed using the * operator, much like the (.) operator of Haskell. fk::f also provides more interesting operators such as >>= and <<= for monadic combinations.

Effects

Effects are functions that take one argument, and return void. They are included, because sometimes we want to produce side effects, but not get a result. fk::e is similar to fk::f, but should be used sparingly.

Predicates

Predicates are functions that take one argument, and return BOOL. fk::p included mainly for filtering functors.

Functors

The Functor is a really useful way to reason about operations on containers like arrays or option-types; like in FunctionalKit, <Functor> is just a protocol that can be implemented by any class. But its requirements are completely different. Where the <FKFunctor> of FunctionalKit was based on a -map: method which took a block argument, <Functor> in FunctionKit requires only that the implementer expose its contents as an array (which can be mapped over using fast enumeration). Then, FunctionKit defines a function which can lift any function into a functor, defined in terms of a for-loop on top of the exposed container contents.

You will recall that the type signature of a function map that lifts another function into a functor is map: : Functor f ⇒ (a → b) → (f a → f b).  Translated into Objective-C parlance, we are looking at a function that takes a closure of type id (^)(id) and returns a new closure of type id <Functor> (^)(id <Functor>).

That means that any function f can be turned into a new function F that will operate on any collection that implements <Functor>. The utility that does this is called the map function, which will give us a new function to be used on a collection; alternatively, I have allowed for functions to be lifted into a functor implicitly on application by the use of the [] operator instead of () for calling. An example:

1
2
3
4
5
6
7
8
9
10
11
12

fk::f f = fk::f(^(NSString *s) {
  return [s stringByAppendingString:@"!"];
});

fk::f F = map(f);

NSArray *arr = [NSArray arrayWithObjects:@"dog",@"cat",nil];

f(@"dog");   // => @"dog!"
F(arr);      // => {@"dog!",@"cat!"}
map(f)(arr); // => {@"dog!",@"cat!"}
f[arr];      // => {@"dog!",@"cat!"}

Monads

The Monad is another way to map over the contents of a collection, and is a superset of Functor. The <Monad> protocol requires only a -flatten method. Then, functions can be composed monadically using the >>= operator, whose type signature is ( ≫  = ): : Monad m ⇒ (a → m b) → (m a → m b).  That is, we take a closure of type id <Monad> (^)(id) and return a new closure of type id <Monad> (^)(id <Monad>). I’m not going to go into detail on the monadic capabilities of FunctionKit, simply because I don’t encourage the overuse of monads, and not a whole lot of value is added by Monad over Functor. Suffice it to say that just as there is provided a utility to lift pure functions into Functors, Monad provides a utility to lift functions returning collections (constituting monadic combinations) into Functors.

Monoids

Monoid is actually one of the most exciting parts of FunctionKit for me. A monoid is a structure that has an identity element id and a binary operator  ⊗ :

$\begin{aligned} id &:: Monoid\ m \Rightarrow m\\ \otimes &:: Monoid\ m \Rightarrow m \to m \to m \end{aligned}$

For the monoid M to be valid, the identity element must be isomorphic to 0 on the addition of natural numbers, or 1 on the multiplication of the natural numbers, etc; the binary operator must also be associative:

$\begin{aligned} \forall x &\in M.\ &x\otimes id &\equiv id\otimes x \equiv x\\ \forall a,b,c &\in M.\ &(a\otimes b)\otimes c &\equiv a\otimes (b\otimes c) \end{aligned}$

The <Monoid> protocol demands that a class expose a zero-value (id, +zero), as well as a binary operation that will “append” values to it ( ⊗ , -append:). FunctionKit provides a function for folding any collection (implementing <Functor>): id fold(id <Functor> cont, id acc, id (^f)(id memo, id val)). In essence, whenever we use this function, we are creating an ad-hoc Monoid.

It follows that we could abstract out a lot of repeated logic for the case when we are folding a collection of Monoids by declaring a function id fold_monoid(id <Functor> cont, id <Monoid> (^f)(id <Monoid> memo, id val)) that would grab the default zero-value of the monoid for us, but let us provide the logic for the folding itself.

Finally, we can declare an even simpler function that will use the default +zero object and -append: method of the Monoid and just fold our collection like a deck of cards: id fold_monoid_append(id <Functor> cont). For instance, I was able to implement +[NSDictionary(Functor) functorWithObjects:] (mapping from the underlying NSArray to the Functor) in terms of the fold_monoid_append and NSDictionary(Monoid):

1
2
3

+ (id <Functor>)functorWithObjects:(NSArray *)anArray {
  return fold_monoid_append(anArray);
}

We simple took all of the items in the array (in this case, each item was an NSDictionary with a single key-value pair) and appended them to each other using NSDictionary’s implementation of <Monoid>.

Type-Fu: boxing and unboxing non-objects

A really important part of FunctionKit is its easy mechanism for boxing and unboxing non-objects using the functions id box<T>(T v) and T unbox<T>(id v). So, we can use box<CGPoint>(CGPointMake(0.3,1.0)), which will use +[NSValue valueWithCGPoint:] to give us an object, automatically. Supported types are int, float, double, BOOL, const char *, SEL, Class, CGPoint, CGRect, CGSize, NSRange, void*, and id (which gives back the same object either way).

But we can do better… Of course, with a little luck, the limited type inference capabilities of C++ will allow us instead of typing box<BOOL>(YES) to get [NSNumber numberWithBOOL:YES], to write box(YES).

And we can have better array syntax… I often see really nasty code the moment people start trying to use arrays, especially with non-object types. FunctionKit provides a better way:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

template <typename T> NSArray *fk::arr (T obj1, ...) NS_REQUIRES_NIL_TERMINATION;
template <typename T> NSArray *fk::lift_arr (T obj);

// we started with the following, which would be better represented as a C-array of ints:
[NSArray arrayWithObjects:
 [NSNumber numberWithInt:2],
 [NSNumber numberWithInt:5],
 [NSNumber numberWithInt:1],
 [NSNumber numberWithInt:45],
 nil];

// but it could be better, if we are intent on using an NSArray:
[NSArray arrayWithObjects:box<int>(2),box<int>(5),box<int>(1),box<int>(45),nil];

// still better:
[NSArray arrayWithObjects:box(2),box(5),box(1),box(45),nil];

// but check this out:
fk::arr<int>(2,5,1,45,nil);

// using C++'s type inference, we can make this even simpler!:
fk::arr(2,5,1,45,nil);

// FunctionKit also provides a way to lift a single value into an array without having to terminate with nil:
fk::lift_arr<int>(3); // => [NSArray arrayWithObject:[NSNumber numberWithInt:3]];

// of course, this is even better:
fk::lift_arr(3);

The problem of arrays is common also in dictionaries. FunctionKit changes all that:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

template <typename K,typename V> NSDictionary *fk::dict (K k1,...) NS_REQUIRES_NIL_TERMINATION;
template <typename K,typename V> NSDictionary *fk::pair (K key, V value);

// let's start with a simple key-value pair, where the value is a boolean, and the key is a string:
[NSDictionary dictionaryWithObject:[NSNumber numberWithBOOL:YES] forKey:@"foo"];
[NSDictionary dictionaryWithObject:box<BOOL>(YES) forKey:@"foo"];
[NSDictionary dictionaryWithObject:$(YES) forKey:@"foo"];
fk::pair<BOOL,NSString *>(YES,@"foo");

// The same concept goes for dictionaries with many pairs
[NSDictionary dictionaryWithObjectsAndKeys:
 [NSNumber numberWithBOOL:YES],@"foo",
 [NSNumber numberWithBOOL:NO],@"bar",
 nil];

[NSDictionary dictionaryWithObjectsAndKeys:
 box<BOOL>(YES),@"foo",
 box<BOOL>(NO),@"bar",
 nil];

fk::dict<BOOL,NSString *>(YES,@"foo",NO,@"bar",nil);

Thanks for reading! The implementation details of parts of this are a bit gnarly, which is why I didn’t go into more detail. If you’re curious, feel free to check out the code on Github!

But everything I’ve just said is false, or at least highly suspect. This is my attempt at proposing steps toward making our tools something really worth boasting of.

The Case Against Cocoa

There are several points I wish to go over.

configuration over convention

Cocoa is a massive, incredibly powerful conglomerate of frameworks that provides object-interfaces for a great many things. Cocoa is so all-encompassing that it is conceivable to write almost any type of application and link only against the Cocoa frameworks.

Keeping in step with its apparent attempt to be everything to everyone, Cocoa appears to be uncomfortable with the concept of declaring any one configuration as the default. A perfect example of this mentality is how when we are setting up an NSWindow, or loading from NSData, we are compelled to pass in all manner of bitmask combinations in order to specify the behavior of the returned object.

Now, this sort of model would make sense if the majority of time, the configuration we needed was variant; the problem is, however, that most of the time, we are passing in the exact same bitmasks, nearly every time we use these APIs. It is the exception, not the rule, that we should want to configure something outside of convention. (If you want an example of ludicrous configuration potential, check out the block-based enumeration method and block signatures for NSArray: the amount of configuration they throw at you at the start is both astounding and laughable.)

unpredictability

One of the first things I did when I started to learn my way around Cocoa was to puzzle over the Class Cluster pattern: it took me a while before I could quite wrap my head around how the Cocoa collections API worked. In short, mutable and immutable interfaces are exposed, but objects created are actually instances of internal subclasses whose implementations are opaque. In theory, this is a neat idea, in that it allows the library to make decisions on efficiency that the consumer of the API shouldn’t have to worry about.

In practice, however, this is a nightmare. I, for instance, do not appreciate when [someArray class] returns __NSArray_M or something ridiculous like that. Likewise, I have encountered bugs that are caused by silly things, like the ability to interchange mutable and immutable objects without warnings.

Another instance of unpredictability is how objects are faulted in Core Data. Objective-C’s fast-and-loose polymorphism is a powerful and a dangerous tool: sometimes the fact that we can does not mean that we should. Often, sending a message to a managed object, whence you should expect to be returned an object of some expected type, you really receive some sort of mocked object that is not what you wanted. This is especially inherent when debugging (though the problem can be avoided by using -[NSObject valueForKeyPath:]).

archaic design

Any feature that adds compile-time checks and contracts to Objective-C is a welcome one, which is why I love protocols so much. Protocols enable something like a less powerful, inverted generic type system, and are indispensable when trying to abstract implementation from interface.

The problem is that because earlier versions of Objective-C did not support protocols, most of our APIs handle this sort of polymorphic behavior by adding categories to the root class.

This is problematic for a few reasons: mainly, though, it makes it much more difficult to enforce constraints, because most objects can be treated as instances of NSObject; all we can do is check whether the object has implemented the required methods at runtime.

Because of this, it is up to us as developers to remember to use objects which implement the right methods with the APIs, for the compiler cannot help us.

The problem is alleviated somewhat with the addition of the formal protocol; we need not check for compliance at runtime, since the compiler will warn us when we pass an incorrect object as an argument whose type specifies some protocol. Yet, I constantly see my colleagues marking their protocol methods as @optional, and checking for implementation on every call. This removes any advantage that the formal protocol gave us in the first place, and is truly counterproductive.

predicate metalanguages

NSPredicate and Key-Value Coding are really cool features of Cocoa, and can be incredibly useful. And the various collection operators (@avg, @count, etc.) that are parsed in key path predicates are pretty cool. For a language that doesn’t have blocks, that is.

This interpreted metalanguage ought to be replaced by a combination of enumeration methods for mapping, reducing, filtering, etc.

mutability-centered design

In the brand of object-oriented programming that Cocoa subscribes to, we spend a lot of time constructing and configuring objects that will then perform tasks for us. A way to think about it is taking a function of several variables (the fields of our class), and currying it in order to allow less verbose partial application (by setting some of the fields in an instance of our class).

There really isn’t anything wrong with this model inherently, except that the way Cocoa implements it is to emphasize the configuration of objects by mutation instead of planned construction. In many cases, the reason we use the mutable object is that it is the only one we can easily configure.

Immutable objects are difficult to configure, because they require us to think of everything at once, and then pass it in some gigantic method, complete with scary dictionaries and bitmasks. Because it is so much more difficult (and expensive) to configure safer, immutable objects than it is to configure unsafe, mutable objects, the entire API favors unnecessary mutability.

In fact, if the way we initialize objects were changed to be more friendly and conducive toward one-off use (with respect to both ease-of-use and performance), we would find ourselves writing code with mostly immutable objects.

Why Cocoa Is Pretty Good

Cocoa isn’t all bad. In fact, it has one strong point which sets it above all other platforms: this is its UI libraries. I’ll be the very first in line to criticize the design of these libraries, but it must be recognized that they are what facilitate the creation of the most beautiful expressions of software the world has ever seen.

Because AppKit and UIKit model the design and guidelines of the two most polished environments ever, they are inherently the best systems for producing beautiful user interfaces. I strongly believe that it is because of Cocoa that we have beautiful Mac and iOS applications, where competing platforms have close to zero beautiful applications.

Making Our Tools Suck Less

What I’m about to suggest represents some dramatic departures from the current Cocoa API design, and will therefore most assuredly never be implemented. But this is my map to Oz.

convention over configuration

The front of the Cocoa API needs to be simplified dramatically: we should have with simple method signatures that do simple things the way we want to do them 99.99% of the time. Then, let us use the complex messages when we need that extra configuration.

Blocks-based APIs need to stop over-specifying; mapping over an array, for instance, should require a block of single arity, not quadruple. In almost every case, for instance, we will have no desire to break enumeration at some point; hence a pointer to a boolean for halting enumeration is almost always superfluous.

type constraint specification and composition

We need more smart use of protocols: an <NSCollection> API (presumably based around <NSFastEnumeration>) would be welcome. APIs that don’t depend on the idiosyncrasies of internal, hidden concrete subclasses of abstract clusters, would be a breath of fresh air, and the way to get there is by composing protocols. Another benefit would be the ability for developers to design their own, pluggable collections that could be used instead of Cocoa’s existing collection classes. This sort of rigorous separation of interface from implementation would have the added benefit of enforcing that the behavior of APIs be based only on predictable aspects of collections as specified by some composition of protocols.

immutable design

We need to stop modeling immutable concepts mutably; in order to make this feasible, a few things need to happen.

If this paradigm-shift is to work, it must taste good to API consumers: one of the main reasons APIs use mutable constructs is that it is so painful to initialize objects with everything needed all at once. It’s not that we actually need to mutate properties of an object during its lifecycle: it’s that we want to have a nice way to set them before we use it. Hence, I propose lazy objects, which allow for pseudo-mutable setup, but become locked once they begin their work. A nice way to do this would be to write have an immutable class whose parameters are set at initialization, and wrap it in a generic proxy which would cache mutations in an NSDictionary until things are ready to roll. Then, the proxy would construct an object of the required type and set it up according to the cached mutations. If I feel like it, I may even create a prototype of this model. But be warned: proxies are cool, but they are also scary. So I may change my mind on this one.

Haters Gonna Hate

There’s more to say, but I’ve said enough for now. I believe that there are a lot of things that need to change in Cocoa, but the still-living-in-the–1980s-NeXTie-thought-police will probably disagree with me. C’est la vie.

Namaste,
JS

So what is this all about? It’s about “noobs”: they’re here, they’re there, they’re everywhere. In software, as certain platforms reach new heights of popularity, the onslaught of confused masses is felt like never before, and yet, we miss a distinction of great importance: the difference between a Learner and a Leech.

The Learner and the Leech have one thing in common: they don’t know something. But the way the two archetypes approach that issue is as opposite as their personalities. The Leech realizes that he has a problem, because he “Hello there i cant mke teh site chaange plz many best regards,, RJ” and he has trouble “(x-code) impirting teh Clas in I-phone XCODE on MAC pC cmputar”. Certainly, realizing the existence of a problem is an admirable step. Indeed, the Leech goes even further, and even asks people for a solution to his problem.

But this is where he distinguishes himself from the Learner; for the Learner realizes that his problem is not that he hasn’t a solution, but that he hasn’t yet understood his problem. Hence, when he asks for help, his question is phrased in terms that will facilitate a more experienced learner to clarify his problem for him. Thence, the solution will follow.

He asks, “What part of this is making X get all weird?” instead of “plz tryin to maek teh simple Rssreader for x-Code, how to rlease object then? thnx”. The Leech asks something that is specific to his desired outcome, but usually over-specifies the circumstances required for success (because he misunderstands the fundamentals of his problem). The Learner, on the other hand, tries to understand his problem in the most general, non-specific terms possible, so that what he learns in that instance will be repeatedly applicable.

being nice

Criticizing a Leech on form (grammar, semantics, spelling, coherence) seems to be considered bad form for a few reasons:

1. We were all once beginners.
2. English is not their first language.
3. It’s not helpful, and it discourages growth of X question/answer site.

At least, so I have heard. In fact, these are all pretty terrible bits of reasoning. That we were all once beginners is irrelevant: in fact, I posit that anyone who truly values learning is always a beginner. What really matters is how we deal with that beginnerhood: are we leeching or learning?

As for English being the second language of many of these people, I remain as steadfastly vengeful as ever. The truth of the matter is that you need to be able to at least write English properly to get anywhere in programming, and to be able to learn from the masters in your field. I know from personal experience that one need not even be close to verbal fluency to be able to write acceptable prose in a foreign language. Hence, I will not exhibit empathy for those who write English like baboons.

The language issue is really an issue of respect: when you write outstandingly poorly while asking for help, you are telling your potential teachers exactly what you think they are worth.

The most interesting of all the assumptions is that criticism of these people is not helpful. For in order to understand this issue, it must be clear what the possible end-states are:

• That the Leech be turned into a Learner.s
• That he should go away, really, just leave. Oh my god. Thank Aqua Buddha.

I think that blunt correction and criticism (criticism without correction is never helpful) will serve to make one of these two things happen to everyone within the Leech community. For in fact, some Leeches are capable of being turned toward Learning, and I suspect that these are the ones who will respond positively to sharp criticism from someone they admire (I know I do!). Upon being criticized sharply, the remaining Leeches will become angry and emotional; if they are criticized often enough, they will become discouraged and leave the rest of the community alone. Thank God.

The ones who leave never to come back are the ones that we most wanted to be rid of:

• They clutter our favorite websites.
• They make us sad during our morning coffee.
• They drive us to the bottle.
• They drive down the cost of labor by their willingness to work for crumbs.

Problem solved.

A ‘bag’ is a multiset, or a set which can contain duplicate objects. CoreFoundation includes CFBag, which is the same concept; for reasons of simplicity, JSBag was implemented on top of NSArray instead of CFBag, but it certainly would be possible if better performance were desired.

Traits

Really, they’re just protocols that have concrete implementations. The way this works is that when a JSBag object is created, the traits (such as mutability) that it needs to have are specified; there are default implementations of each of these traits included (the implementation is in the form of a class adopting the trait’s protocol), but these can be switched out for alternate implementations. You can even add your own traits.

The way this all works is that when the JSBag object receives a message, it looks through its enabled traits until it finds the one which declares a corresponding method; then, it will look through its traits-to-implementation-class map to find the class that implements that method. Then, it grabs the IMP from that class and applies it to self with whichever arguments are necessary.

Whereas in the traditional Class Cluster, the abstract superclass tends to spend a lot of time jiggering about how to delegate its unimplemented tasks, and the concrete subclasses tend to duplicate a lot of functionality among themselves, this system allows pluggable implementations for traits that can easily be turned on and off. So, the JSMutableBag subclass of JSBag actually only implements one method, which is to override the enabled traits to include @protocol(JSMutableBag). Other similar subclasses of JSBag could be created which add support for more, user-defined traits.

Drawbacks

The idea of this is not to use alternate implementations that carry down abstract bits from a superclass: the idea is to compose functionality by registering implementations of traits, and then dispatching tasks dynamically to them. That means that a few benefits of the traditional Class Cluster are lost, namely the ability for implementations to have alternative instance-variable layouts.

In the end, I think that the performance gain from that sort of optimization is going to be minimal for most things (remember, YAGNI). So, I believe that in many cases, a trait-composition design like that shown in JSBag could be useful.

Design

You may note that I’ve avoided using specific types of collections in my interface, because in most cases, all that matters is that they can be iterated over. Hence, instead of taking parameters of type NSArray* or NSSet* for some things, I’ve generalized to id <NSFastEnumeration>. Since JSBag adopts <NSFastEnumeration>, that means that methods which take collections as parameters can also take JSBag objects. This is incredibly useful, as it makes having methods like +bagWithArray:, +bagWithSet:, +bagWithBag:, etc. actually redundant:

+ (id)bagWithCollection:(id <NSFastEnumeration>)enumerable;

will handle all of this for us. This made implementing <NSCopying>, <NSMutableCopying>, and several other key bits absolutely trivial:

1
2
3
4
5
6
7

- (id)copyWithZone:(NSZone *)zone {
  return [[JSBag allocWithZone:zone] initWithCollection:self];
}

- (id)mutableCopyWithZone:(NSZone *)zone {
  return [[JSMutableBag allocWithZone:zone] initWithCollection:self];
}

Remember that messaging JSMutableBag vs. JSBag for in this case only changes the default enabled traits from {<JSBasicBag>} to {<JSBasicBag>,<JSMutableBag>}. That’s pretty cool.

Moving Forward

I believe that this trait-composition approach could be generalized to be usable in many contexts. As I improve it, and make it more flexible, I hope to find neat uses for it. In the meanwhile, clone or fork JSBag on Github!

Hence, my new shitlist.

1. Never embed your web application in a native application; that is to say, do not slap a webview above a UITabBarController and call it good. This is a sin.

2. Never use controls which attempt to mimic those of the substrate platfom: the bullshit interaction of your iPhone-y navigation bar will only serve to highlight your incompetence to experienced users, and confuse inexperienced ones.

3. Do not make some sort of header attempt to hover at the top of your view, unless you have coded your own scrolling system (like in PastryKit). All the time, I see bullshit websites that have some sort of terrible navigation bar that sits at the top of the view, no matter how far down you are scrolled; but because it is bullshit, when you start dragging to scroll, the header disappears, and reappears when scrolling has stopped. This is bullshit.

4. Don’t overuse animation. WebKit has some neat stuff these days, and in an attempt to make web apps feel at home, some devs insist of using view animations (like in an iOS navigation controller). Don’t do this: it’s often laggy, and takes away from the speed of a transition that ought to be instant! When I do something in a native navigation controller, I expect some animation-feedback; when I tap a link in a website, I expect to brought immediately to my destination.

5. Don’t, for the love of God, try to make it look like iOS. The whole reason for web applications is that your don’t have to spend resources building a separate app for each platform. If you are content to force all users, regardless of their platform, to use an app that looks like you disemboweled iOS and filled her with bullshit, then you ought to just make a nice native app for iOS and ignore the other platforms.

Note: @stevestreza, the creator of the awesome web app Swearch, informs me that it’s possible to make WebKit animations 60fps on iPhone 3GS and up, if you code them the hell properly. The problem is that most developers do a poor job at this, I suppose.

What you must do.

If you must make a mobile web app, make it as simply as possible, without lots of custom controls. In fact, just try to make it exactly like Pinboard; 37signals also did a great job with Basecamp (though I disagree with their use of animated transitions). Last thing: for the sake of iOS users, please make sure that your app is capable of being clipped to the home screen and opening in its own chromeless browser.

The two common formulae are:

(1) níŋ-U.GUD-e pa        mu-na-è
    niŋ??=e     pa=0      mu-na-e-0
    ??=LOCT     CVNE=ABS  CP-DAT3-manifest-ABS3I
    'For him, he made manifest the ancient things.'
    'For him, he made manifest the appropriate things.'


(2) ur-saŋ   níŋ-U.GUD-e gù        ba-a-dé
    ursaŋ=0  niŋ??=e     gu=0      ba-?-de-0
    hero=VOC ??=LOCT     voice=ABS CP-ERG2-pour-ABS3I
    'Hero, you called for (=pour voice) for the ancient things.'
    'Hero, you called for propriety.'

Formula 2 appears in the Stele of the Vultures of Eannatum (albeit in slightly altered form):

é-an-na-túm á tuku-e mu-pàd-da <d>nin-ŋír-sú-ka-ke4
'I, powerful Eannatum, called by Ningirsu,'
é-an-na-túm-me kur a-ne-šè ŋá-̵ŋá-dè
'(I) Eannatum, in order to lay down the land before him,'
níŋ-ul-lí-a-da gù nam-mi-dé
'I called for (?/ proclaimed) the ancient things!'

The main difference beyond the use of the comitative instead of the locative-terminative is that in this instance, we get a longer form of ul (ul-lí), wherefore we know that du7 is not a plausible reading for this instance.

Formula 1 gets a similar break in Ur-Namma:

<d>nanna dumu-sag <d>en-líl-lá lugal-a-ni
'For his master Nanna, sweet son of Enlil:'
ur-<d>namma nita kal-ga lugal úri<ki>-ma
'Ur-Namma, a mighty man, King of Ur,'
lugal ki-en-gi ki-uri-ke4 lú é <d>nanna in-dù-a
'King of Sumer and Akkad, who built Nanna's Temple:'
níŋ úl-lí-a-ke4 pa mu-na-è
'He made manifest the things of the distant past.'

Again, there is a slight difference from the more common formula (the extra genitive, uli-ak=e instead of uli=e). But the basic meaning here is quite clear.

Because we find both Formulae (with slight variation) occasionally using longer stems of ul, which are incompatible with a reading du7, it is tempting to say that the correct reading is ul instead of du7 in all instances of these formulae. But I err on the side of caution: in all instances which have only níŋ-U.GUD-e, du7 as a reading for U.GUD works just fine semantically. So, either ul is the correct reading in all cases, or there are variants of the formulae which also refer to propriety.

• how “nerds” (what a lot of us have inexplicably taken on as a positive term for our demographic) are awful to each other, and need to lighten up and return to the old days of mutual good-feelings and social hacking. We apparently need to be more “excellent to each other”.

• how women are constantly and consistently disrespected in our community. They don’t get invited to conferences, or some brave guy tried to hit on them at a party, or they are assumed to not be software developers, or some other grievance.

Be Excellent To Each Other

I’ve encountered my fair share of impatient disrespect on the internet. It tends to come from two sorts of people:

• idiot teenagers who think they know something, and refuse to stop arguing obscure topics with experts
• cranky old veterans who disagree with unorthodox ideas

The first category is unforgivable, but I have a lot of respect for the veterans. Whether I’m right or not (I usually am under the impression that I am), discussions I’ve had with cranky veterans have always been extremely valuable to me. These are folks who have been doing this stuff for so long that they are bound to at least have really good reasons for their strongly-held opinions. I like to figure things out the hard way, so I often ignore their advice; but frequently (though not always), I’ll come back several months later and decide that the cranky veteran was right. I’m actually glad these folks are so hard on me, since it impresses the importance of their opinion upon me all the more.

I don’t take rude comments from my betters personally, and neither should you. You should listen very carefully to what they say, and you might learn something.

I believe that arguments are more effective the more civilly they are conducted; there comes a point, however, when someone must be given license to throw away the rules of politeness in order to inflict intellectual justice on a small soul like me.

My experience is that if you interpret things correctly, most of our community really are excellent to each other. And yet it remains so fashionable go complain and moralize about the state of our interpersonal skills.

Sexist Atmosphere

The other irritating meme that keeps coming up is that our community is horrible to women. Apparently, we are supposed to:

• invite conference speakers based on their gender, as opposed to their fame and talent
• assume that all women we meet at or near technical conferences are software developers
• not acknowledge a woman’s gender in a friendly way
• ignore our sexual imperative and never introduce ourselves to women at technical conferences with the purpose of establishing a more-than-friendly relationship with them
• never try to explain our work in layman’s terms to women who have introduced themselves to us as nontechnical beauty-models

Many of the examples brought up by ever-active sexism-crusaders either involve false pretenses and entrapment (in the case of our supermodels-pretending-to-be-Luddites), or idiot douche-bag teenagers trying to be macho. I’ve never met a real male software craftsman who is not thrilled at the idea of more women entering the workforce, or who would behave inappropriately to a female colleague, or who would purposely exclude women from panels or conferences. Sexism in our industry is tragic when it happens, but there seems to be a lot more complaining about sexism than there is actual sexism going on.

Sidebar

“You don’t know what it’s like being a woman. Grow a vagina and then come back and argue with me about sexism.”

Ugh. I’ve heard this desperate argument more times than I’d like to admit. The idea that men have no say in discussions of sexism (discussions, mind you, which are designed to generalize and condemn members of my sex as bigots) is laughable. If I need a vulva in order to discuss gender-politics with you, I think I may be in need of a better conversational partner.

Let’s make nice stuff, and stop politicizing every little thing. In essence, I’m asking the brigade of angry sexism-crusaders to stop assuming that the average male software developer is a pig: I suppose I could say that I’m asking them to be “excellent” to us.

I’ve seen a few solutions to this problem; the one that came closest ended up overriding

1
2

-[NSSliderCell startTrackingAt:inView:],
-[NSSliderCell continueTracking:at:inView:]

and cleverly switching allowsTickMarkValuesOnly on and off at opportune moments. This worked visually, but the data that was streamed from the slider didn’t actually snap until after tracking ended. This is obviously a non-starter, if you’re showing continuous feedback for your slider.

My solution

So, I’ve come up with a simpler and slightly more clever solution, which behaves just as one would expect it to.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

@interface JSSnappingSliderCell : NSSliderCell
@end

@implementation JSSnappingSliderCell
static const CGFloat kSnappingZone = 10.0f;

- (BOOL)continueTracking:(NSPoint)lastPoint at:(NSPoint)currentPoint inView:(NSView *)controlView 
{
  CGPoint snapToPoint = currentPoint;

  for (NSUInteger i = 0; i < self.numberOfTickMarks; i++)
  {
    NSRect tickMarkRect = [self rectOfTickMarkAtIndex:i];
    if (ABS(tickMarkRect.origin.x - currentPoint.x) <= kSnappingZone) 
    {
      snapToPoint = [self rectOfTickMarkAtIndex:i].origin;
      break;
    }
  }

  return [super continueTracking:lastPoint at:snapToPoint inView:controlView];
}

@end

Enjoy, and do let me know if you have a better idea!

I’m currently in my second year at UC Berkeley as a Linguistics major, and next year will be my last. As I am drawn nearer to the point at which I likely leave academia (and linguistics) forever, I realize that over the past few years, I’ve had a lot of little turning points which have marked changes in my life which can’t be reversed. Each of these aborted paths is, however, but a siren along the route toward what I really want out of life.

Jazz Musician

When I was in middle school, I played piano in the “Jazz” band there, and I thought I was pretty hot shit. As I learned when I entered high school, I was quite the opposite. My brother was the guitarist in the Jazz band there, and my family had developed a relationship with the director. I suspect that when I auditioned to join the group, I was admitted not because I was any good (for I wasn’t), but because the director saw my brother’s talent and had high hopes that I was capable of being coached toward an equal level of skill.

The story from there is one that is often repeated in trite sports sagas: this awkward kid who can’t do shit is thrown in with the wolves, makes a fool of himself every day, and at some point starts to get it. Not to say that he had become adequate; rather, he had grown enough that his teammates gained some level of respect for him, and his coach treated him like family.

Then came Junior year. Most of the kids who were better than me had graduated, and I had been promoted to rhythm section leader. I was starting to come into my own. The veterans in the group looked at me with that “Yeah, you’re all right” face, and, even though I knew that I was only OK, I started to think that I was pretty great. On a few occasions, my real inadequacy surfaced and I remembered how much I really sucked. The problem was that a lot of people sucked even more than I did, so they mistakenly looked up to me.

Senior year, I actually was some hot shit. I was the assistant director of the band, and the director of the quintet. And I was actually pretty OK. Whereas in previous years, I had the dubious honor at all the festivals of winning “soloist awards” (which were basically given to anyone who got up and played something, no matter how poorly), this year I was getting recognized as best pianist in show, or best rhythm section soloist, and so forth. That was actually pretty neat; it tickled my ego to be distinguished among young musicians who have today gone on to accomplish great things.

The last time I played piano in concert, I was accompanied by Mel Brown himself, the grandfather of the Portland Jazz scene; during my solo on the Dexter Gordon tune, he smiled at me in surprise, and afterwards he shook my hand and told me how proud he was of me, how far he knew I had come. And then I was done with that part of my life. I was going to college to study something entirely different.

Linguist, Assyriologist, Classicist

I didn’t apply to enough colleges, because I was overconfident that Harvard, Yale, Cornell or Berkeley would admit me. Though the latter two were afterthoughts, they were the only ones to offer me admittance. Cornell seemed like a bleak place that would make me insane, and I’d had my heart set on Boston; I ended up “settling” for Berkeley.

As soon as I got here, I dived into things that I consider awesome: I became the only undergraduate to take Sumerian, for one. And the story repeats itself: my professor nurtured my interest in the field of Cuneiform languages, provided me with research opportunities, and did everything in his power to help me progress in my path to graduate school.

Next semester, my Sumerian professor goes on sabbatical, but he has invented a cuneiform reading group to essentially keep our class going; I suspect that he did this at least partly in order to help me continue in my studies.

I also took Ancient Greek, and was distinguished as the best student of elementary Greek in that year by the man who wrote the textbook. This year, I continued my Greek education with mostly the same group of Classics comrades in reading Plato’s Apology. And as the rest of them move on next semester to read Homer, I abandon them for the purpose of knocking out school requirements so I can graduate early. And because I simply won’t take a class that goes past 4PM.

So, I bade my Greek comrades (τοῖς Ἑλληνικοῖς ἑταίροις ταῖς τε Ἑλληνικαῖς) farewell after exams, and went on my way. Next year, I shall have to do the same to the graduate students and geriatric auditors in my Sumerian group, of whom I’ve grown quite fond in the past few years.

λx. Software Developer x ⇒ Landowner x ∧ Retiree x

I’m graduating school early (and probably not doing graduate school) not because I don’t like it, but because I cannot justify going into debt tens of thousands of dollars every year, when I could be making tens of thousands of dollars every year. The life of the starving academic is not for me: by the time I would be experienced enough to deserve tenure, I doubt that the construct will even exist. The way things are going, after all the real professors die, I should think they’ll be replaced by streams of graduate students who are used until exhaustion, and then replaced.

I’m also not leaving because I think that software development is terribly more interesting than Linguistics.¹ In fact, there are many aspects of it which I find dull, and even irritating (such as dealing with clients, who will always be several years behind in understanding things). But I’m pretty all right at software development, and at least for now, that profession commands high wages.

Mike Monteiro says that when faced with a life decision, you must always choose the path which will lead you to your ultimate goal; and whatever that ultimate goal is, you must own it entirely. My goal isn’t to be a software developer living the startup high any more then it is to be a starving academic, or a starving musician: my goal is to be a landowner with a respectable income, who can afford to have a nice house, clothes made for him, a few dogs, and some sheep and goats.

In the meantime, I’m happy to be whatever kind of software developer people are paying for. If that means writing soul-crushing apps for clueless clients, and having to use the word “gamification” with a straight face, then so be it. When I’m seventy, I doubt that retirement will even be “a thing” anymore for most people; I figure I’ll have won the game if I can build for myself a life full of my favorite anachronisms: savings, land, and my own quiet house.

In the untyped lambda calculus, a pair (x, y) is encoded as a function which takes two values x, y, yielding a new function that takes an accessor function f as its argument (that is, f selects either the left or the right argument):

$\begin{aligned} \textbf{pair} &:= \lambda xyf. f\,xy\\ \textbf{fst} &:= \lambda p. p\, (\lambda xy. x)\\ \textbf{snd} &:= \lambda p. p\, (\lambda xy. y) \end{aligned}$

So, the following reductions can occur:

$\begin{aligned} \textbf{pair}\; ab &\equiv (\lambda xyf. f\,xy)\; ab\\ &\to \lambda f. f\,ab\\ \textbf{fst}\; (\textbf{pair}\; ab) &\equiv \textbf{fst}\; (\lambda f. f\,ab)\\ &\to (\lambda p. p\, (\lambda xy. x))\; (\lambda f. f\,ab)\\ &\to (\lambda f. f\,ab)\; (\lambda xy. x)\\ &\to (\lambda xy. x)\; ab\\ &\to a\\ \textbf{snd}\; (\textbf{pair}\; ab) &\equiv \textbf{snd}\; (\lambda f. f\,ab)\\ &\to (\lambda p. p\, (\lambda xy. y))\; (\lambda f. f\,ab)\\ &\to (\lambda f. f\,ab)\; (\lambda xy. y)\\ &\to (\lambda xy. y)\; ab\\ &\to b\\ \end{aligned}$

Translating our untyped example into the typed lambda calculus naïvely doesn’t change much of anything. The main features of this new calculus are polymorphic types (α, β, γ…), and type-level functions corresponding to universal quantification. Types are abstracted over using a capital lambda.

$\begin{aligned} \textbf{pair} &:= \Lambda\alpha\beta\gamma. \lambda x^\alpha y^\beta f^{\alpha\to\beta\to\gamma}. f\,xy\\ \textbf{fst} &:= \Lambda\alpha\beta\gamma. \lambda p^{(\alpha\to\beta\to\alpha)\to\gamma}. p (\lambda x^\alpha y^\beta. x)\\ \textbf{snd} &:= \Lambda\alpha\beta\gamma. \lambda p^{(\alpha\to\beta\to\beta)\to\gamma}. p (\lambda x^\alpha y^\beta. y) \end{aligned}$

However, this is problematic. What this definition of pair ends up saying is that for all types α, β, γ, there is a function that will retrieve a value in γ from a pair in (α, β). This, however, is only true inasmuch as γ is either α or β. Thus, our current definition will allow more incorrect programs than is acceptable in a typed (but not dependently-typed) language. What we really need is to constrain γ:

$\begin{aligned} \textbf{pair} &:= \Lambda\alpha\beta. \lambda x^\alpha y^\beta f^{\alpha\to\beta\to(\alpha\lor\beta)}. f\,xy\\ \textbf{fst} &:= \Lambda\alpha\beta. \lambda p^{(\alpha\to\beta\to\alpha)\to\alpha}. p (\lambda x^\alpha y^\beta. x)\\ \textbf{snd} &:= \Lambda\alpha\beta. \lambda p^{(\alpha\to\beta\to\beta)\to\beta}. p (\lambda x^\alpha y^\beta. y) \end{aligned}$

So, we have created a typed encoding of the Church Pair which only allows accessors which return a value of the correct type.

Encoding our typed Church Pair in Haskell

> {-# LANGUAGE MultiParamTypeClasses #-}
> {-# LANGUAGE Rank2Types #-}
> {-# LANGUAGE FlexibleInstances #-}
> {-# LANGUAGE IncoherentInstances #-}
> {-# LANGUAGE UnicodeSyntax #-}

> module ChurchPair where
> import Prelude hiding (fst, snd)

The first order of business will be to implement the disjunction constraint (Λ αβ. α ∨ β) in Haskell. To do this, we can use a type class:

> class TypeOr α β γ

and inhabit it with the proper combinations:

> instance TypeOr α β α
> instance TypeOr α β β

Now, we can create a type synonym (for the sake of convenience) that encapsulates the structure of pairs:

> type Pair α β = ∀ γ. TypeOr α β γ ⇒ (α → β → γ) → γ

A Pair over (α, β) is function that takes a function that returns one of its elements. Note that we cannot specify within this non-dependent type system that the result of this accessor actually be one of the elements, but the (TypeOr α β γ) constraint allows us to at least ensure that the result is of the type of either element in the pair.

And now, given two values, we can construct a Pair:

> pair :: α → β → Pair α β
> pair x y f = f x y

The accessors are easily written, and their type annotations make clear their function:

> fst :: Pair α β → α
> fst p = p $ \x y → x

> snd :: Pair α β → β
> snd p = p $ \x y → y

Incidentally, fst and snd can also be defined in terms of library functions:

> fst' p = p const
> snd' p = p $ flip const

To demonstrate the benefit our typing constraints, try the following:

badAccessor :: Pair α β → String
badAccessor p = p $ \x y → "Hello" -- type error

It is impossible to create an accessor of the wrong type (unless the accessor itself is the bottom, in which case you will have a runtime error).

Building on the work of sigfpe’s From Monoids to Monads and monoidal’s Kind polymorphism in action (which demonstrates kind polymorphism in the Ultrecht Haskell Compiler), we can unify Monoid and Monad under one type class in GHC 7.4.

So, the quote at the beginning is true, but with a few qualifications. As most beginning functional programmers know it, the monoid is a structure that has an identity element id and a binary operator  ⊗ :

$\begin{aligned} \text{class} &\textbf{Monoid}\ (m : \star) \text{ where}\\ & id: m\\ & \otimes: m \to m \to m \end{aligned}$

For the monoid m to be valid, the id must be the identity with respect to the operator  ⊗ , like 0 is to  +  on natural numbers, or 1 to  × , etc; the binary operator must also be associative:

$\begin{aligned} \forall x &: m.\ &x\otimes id &\equiv id\otimes x \equiv x\\ \forall a,b,c &: m.\ &(a\otimes b)\otimes c &\equiv a\otimes (b\otimes c) \end{aligned}$

This kind of monoid does not bear the sort of abstraction required to unify it with Monad, which is rather different:

$\begin{aligned} \text{class} &\textbf{Functor}\ m \Rightarrow \textbf{Monad}\ (m : \star\to\star) \text{ where}\\ & \eta: \forall\alpha:\star. (\textbf{Id}\ \alpha \to m\,\alpha) \\ & \mu: \forall\alpha:\star. (m\, (m\,\alpha) \to m\,\alpha) \end{aligned}$

In fact, η is a natural transformation¹ from the Identity functor to another functor m; μ is a natural transformation from m² to m (that is, from m applied twice to m applied once).

A Difference of Kinds

You’ll note that our Monad and Monoid operate in totally different worlds: a difference of kinds. That is, an instance of the former is a type of values (m:  ⋆ ), whereas an instance of the latter is an arrow from one type to another (a type constructor, m:  ⋆  →  ⋆ ). By analogy, then, the former’s functions should be natural transformations in the latter.

This makes fine sense, but the question of what to do with id remains: why does it have an input in Monad, but not in Monoid? If we are going to understand these functions as arrows between objects in a category, then id must have an input. As a natural transformation in Monad, its input is the identity functor; as a simple function in Monoid, its input should be $\varnothing$, nothing.

If we uncurry  ⊗ , then its type becomes (m × m → m); this adjustment brings its type in line with that of μ. So, we can build the following (incomplete and flawed) generalization over an identity element id and a type-operator  × :

$\begin{align} \text{class} &\textbf{Monoid}\ (id: k)\ (\times : k\to k\to \star)\ (m : k)\ \text{ where}\\ & id: id \to m\\ & \otimes: m\times m \to m \end{align}$

$\begin{align} \text{instance} &\textbf{Num}\ \alpha \Rightarrow \textbf{Monoid}\ \varnothing\ (\Lambda x\,y. (x,y))\ \alpha\ \text{ where}\\ & id = const\ 0\\ & \otimes = uncurry\ (+) \end{align}$

$\begin{align} \text{instance} &\textbf{Monoid}\ \textbf{Id}\ (\Lambda f\,g\,\alpha. f\ (g\,\alpha))\ [\,]\ \text{ where}\\ & id\ (\textbf{Id}\ x) = [x]\\ & \otimes [xs] = xs \end{align}$

But this doesn’t work, since the type of id for our second (monadic) instance reduces to Id → [], which doesn’t type-check: that is, the kind of ( → ) is  ⋆  →  ⋆  →  ⋆ , but the kind of each of its operands in id is already ( ⋆  →  ⋆ ). What this means is that for monadic instances of Monoid, we need an arrow type constructor of kind ( ⋆  →  ⋆ ) → ( ⋆  →  ⋆ ) →  ⋆ . So we need to abstract over kind of arrow constructor:

$\begin{align} \text{class} &\textbf{Monoid}\ (\leadsto\;: k\to k\to\star)\ (id: k)\ (\times : k\to k\to \star)\ (m : k)\ \text{ where}\\ & id: id \leadsto m\\ & \otimes: m\times m \leadsto m \end{align}$

A normal monoid deals with function arrows and pairs:

$\begin{align} \text{instance} &\textbf{Num}\ \alpha \Rightarrow \textbf{Monoid}\ (\to)\ \varnothing\ (\Lambda x\,y. (x,y))\ \alpha\ \text{ where}\\ & id = const\ 0\\ & \otimes = uncurry\ (+) \end{align}$

A monadic monoid deals with natural transformations and composed functors:

$\begin{align} \text{instance} &\textbf{Monoid}\ (\Lambda f\,g\,\alpha. f\,\alpha\to g\,\alpha)\ \textbf{Id}\ (\Lambda f\,g\,\alpha. f\ (g\,\alpha))\ [\,]\ \text{ where}\\ & id\ (\textbf{Id}\ x) = [x]\\ & \otimes [xs] = xs \end{align}$

The Haskell Version

We’ll need to turn on a bunch of GHC extensions.

> {-# LANGUAGE PolyKinds #-}
> {-# LANGUAGE MultiParamTypeClasses #-}
> {-# LANGUAGE FlexibleInstances, FlexibleContexts #-}
> {-# LANGUAGE UndecidableInstances #-}
> {-# LANGUAGE FunctionalDependencies #-}
> {-# LANGUAGE RankNTypes #-}
> {-# LANGUAGE TypeOperators #-}
> {-# LANGUAGE DeriveFunctor #-}
> {-# LANGUAGE UnicodeSyntax #-}

> module GeneralizedMonoid where
> import Control.Monad (Monad(..))
> import Data.Monoid (Monoid(..))

First we define the type class Monoidy:

> class Monoidy (~>) comp id m | m (~>) → comp id where
>   munit :: id ~> m
>   mjoin :: m `comp` m ~> m

We use functional dependencies to help the typechecker understand that m and ~> uniquely determine comp (times) and id.

This kind of type class would not have been possible in previous versions of GHC; with the new kind system, however, we can abstract over kinds!² Now, let’s create types for the additive and multiplicative monoids over the natural numbers:

> newtype Sum a = Sum a deriving Show
> newtype Product a = Product a deriving Show
> instance Num a ⇒ Monoidy (→) (,) () (Sum a) where
>   munit _ = Sum 0
>   mjoin (Sum x, Sum y) = Sum $ x + y
> instance Num a ⇒ Monoidy (→) (,) () (Product a) where
>   munit _ = Product 1
>   mjoin (Product x, Product y) = Product $ x * y

It will be slightly more complicated to make a monadic instance with Monoidy. First, we need to define the identity functor, a type for natural transformations, and a type for functor composition:

> newtype Id α = Id { runId :: α } deriving Functor

A natural transformation (Λ f g α. (f α) → (g α)) may be encoded in Haskell as follows:

> newtype NT f g = NT { runNT :: ∀ α. f α → g α }

Functor composition (Λ f g α. f (g α)) is encoded as follows:

> newtype FC f g α = FC { runFC :: f (g α) }

Now, let us define some type T which should be a monad:

> newtype Wrapper a = Wrapper { runWrapper :: a } deriving (Show, Functor)
> instance Monoidy NT FC Id Wrapper where
>   munit = NT $ Wrapper . runId
>   mjoin = NT $ runWrapper . runFC

With these defined, we can use them as follows:

ghci> mjoin (munit (), Sum 2)
      Sum 2
ghci> mjoin (Product 2, Product 3)
      Product 6
ghci> runNT mjoin $ FC $ Wrapper (Wrapper "hello, world")
      Wrapper {runWrapper = "hello, world" }

We can even provide a special binary operator for the appropriate monoids as follows:

> (<+>) :: Monoidy (→) (,) () m ⇒ m → m → m
> (<+>) = curry mjoin

ghci> Sum 1 <+> Sum 2 <+> Sum 4
      Sum 7

Now, all the extra wrapping that Haskell requires for encoding this is rather cumbersome in actual use. So, we can give traditional Monad and Monoid instances for instances of Monoidy:

> instance Monoidy (→) (,) () m ⇒ Monoid m where
>   mempty = munit ()
>   mappend = curry mjoin

> instance (Functor m, Monoidy NT FC Id m) ⇒ Monad m where
>   return x = runNT munit $ Id x
>   x >>= f = runNT mjoin $ FC (f `fmap` x)

And so the following works:

ghci> mappend mempty (Sum 2)
      Sum 2
ghci> mappend (Product 2) (Product 3)
      Product 6
ghci> join $ Wrapper $ Wrapper "hello"
      Wrapper {runWrapper = "hello" }
ghci> Wrapper "hello, world" >>= return
      Wrapper {runWrapper = "hello, world" }

If you got this far…

I hope you enjoyed that! I can’t express enough my thanks to the people who came before me and helped me indirectly to refine my ideas and understanding of the relationship between monads and monoids. Additionally, a shout-out to the GHC team for adding kind polymorphism!

The latest versions of the Clang compiler extend the Objective-C language with related return types, which allow a limited form of covariance to be expressed. Methods with certain names (alloc, init, etc.) are inferred to return an object of the instance type for the receiver; other methods can participate in this covariance by using the instancetype keyword for the return type annotation.

Typically, this feature is used for convenience constructors which would previously have returned id. However, we can also use it to encode statically-typed collections without full-blown generics.¹

Decorating Types with Protocols

If Objective-C had parametric polymorphism (that is, the ability to abstract over types), then a simple typesafe collection would be trivial:

1
2
3
4

@protocol OrderedCollection[V]
- (V)at:(NSUInteger)index;
- (void)put:(V)object;
@end

With instancetype, we support a subset of parametric polymorphism: that is, we can abstract over one type (the type of an instance of the implementing class), and we are limited to referring to this type in method return types.² So, we can approximate something rather close, but slightly less safe and precise:

1
2
3
4

@protocol OrderedCollection
- (instancetype)at:(NSUInteger)index;
- (void)put:(id)object;
@end

Since we are limited to abstracting over the type of self, the static type of any such collection must actually be the type of its elements decorated by the <OrderedCollection> protocol. So, a collection of strings statically be understood to be a single string, decorated with collection methods:

1
2
3

NSString <OrderedCollection> *strings = ...;
[strings put:@"hello,"];
[strings put:@"world!"];

Higher Order Messaging

The fact that the static type of such a collection is the product of the type of its elements and a collection trait gives rise serendipitously to the applicability of higher-order-messaging, or HOM. For instance, what does it mean if you send NSString-messages to an object NSString <OrderedCollection>*? It makes sense to treat the collection as a Functor and map the message over its elements:

1
2
3
4
5

for (NSString *upperString in [strings.uppercaseString substringFromIndex:1])
  NSLog(@"%@", upperString);

// => ELLO,
// => ORLD!

An Implementation

We’ll implement covariant protocols <OrderedCollection, MapCollection>.

The collection interfaces

1
2
3
4
5
6
7
8
9

@protocol OrderedCollection <NSFastEnumeration>
- (instancetype)at:(NSUInteger)index;
- (void)put:(id)object;
@end

@protocol MapCollection <NSFastEnumeration>
- (instancetype)at:(id)key;
- (void)put:(id)object at:(id)key;
@end

Collection Proxies

We will use proxy objects to implement both the HOM and the checked collection accessors. First, we start with an abstract base CollectionProxy class, in terms of which proxies for both arrays and dictionaries will be expressed:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159

@interface CollectionProxy : NSObject
@property (strong) id target;
@property (assign) class elementClass;

- (id)initWithTarget:(id)target;

+ (Class)collectionClass;

// Subclasses will provide a technique for mapping an element in one
// collection to a new element in another.
- (void)appendMappedObject:(id)mapped fromObject:(id)original toBuffer:(id)buffer;

// Subclasses may wish to map over an object derivable from object
// given in fast enumeration. For instance, dictionaries map over
// values, rather than keys.
- (id)redirectIteration:(id)object;
@end

@implementation CollectionProxy
@synthesize target, elementClass;

- (id)initWithTarget:(id)aTarget {
  if ((self = [super init]))
    target = aTarget;

  return self;
}

- (id)init {
  return [self initWithTarget:[self.class.collectionClass new]];
}

- (NSMethodSignature *)methodSignatureForSelector:(SEL)sel {
  if ([self.class.collectionClass instancesRespondToSelector:sel])
    return [self.class.collectionClass instanceMethodSignatureForSelector:sel];

  return [self.elementClass instanceMethodSignatureForSelector:sel];
}

- (BOOL)respondsToSelector:(SEL)aSelector {
  return [super respondsToSelector:aSelector] 
      || [target respondsToSelector:aSelector] 
      || [self.elementClass instancesRespondToSelector:aSelector];
}

- (void)forwardInvocation:(NSInvocation *)invocation {
  // If the collection itself responds to this selector (like if
  // someone sent -count), we'll forward the message to it.
  if ([target respondsToSelector:invocation.selector])
    return [invocation invokeWithTarget:target];

  // If the invocation returns void, we still want to invoke it, but
  // we don't want to try to do anything with its results.
  BOOL returnsValue = strcmp("v", invocation.methodSignature.methodReturnType) != 0;
  id buffer = returnsValue ? [self.class.collectionClass new] : nil;

  for (id obj in target) {
    [invocation retainArguments];
    [invocation invokeWithTarget:[self redirectIteration:obj]];

    void *outPtr = NULL;
    if (returnsValue) {
      [invocation getReturnValue:&outPtr]; 

      // We marshall the return value of the invocation back into our space.
      id mapped;
      if ((mapped = objc_unretainedObject(outPtr)))
        [self appendMappedObject:mapped fromObject:obj toBuffer:buffer];
    }
  }

  if (returnsValue && [buffer count] > 0) {
    // Build up a new proxy of the same kind to return.
    CollectionProxy *proxy = [[self.class alloc] initWithTarget:buffer];

    // We marshall the proxy out of our space and set it as the return
    // value of our invocation.
    invocation.returnValue = &(const void *){
      objc_unretainedPointer(proxy)
    };
  }
}

// Default behavior

+ (Class)collectionClass { return nil; }
- (void)appendMappedObject:(id)mapped fromObject:(id)original toBuffer:(id)buffer {}
- (id)redirectIteration:(id)object { return object; }

@end

@interface OrderedCollectionProxy : CollectionProxy
@end

@interface MapCollectionProxy : CollectionProxy
@end


@implementation OrderedCollectionProxy

- (id)initWithTarget:(id)target {
  if ((self = [super initWithTarget:target]) && [target count])
    self.elementClass = [[target lastObject] class];

  return self;
}

+ (Class)collectionClass {
  return [NSMutableArray class];
}

- (void)appendMappedObject:(id)mapped fromObject:(id)original toBuffer:(id)buffer {
  [buffer addObject:mapped];
}

- (void)put:(id)object {
  assert([object isKindOfClass:self.elementClass]);
  [self.target addObject:object];
}

- (instancetype)at:(NSUInteger)index {
  return [self.target objectAtIndex:index];
}

@end


@implementation MapCollectionProxy

- (id)initWithTarget:(id)target {
  if ((self = [super initWithTarget:target]) && [target count])
    self.elementClass = [[target allValues].lastObject class];

  return self;
}


+ (Class)collectionClass {
  return [NSMutableDictionary class];
}

- (void)appendMappedObject:(id)mapped fromObject:(id)key toBuffer:(id)buffer {
  [buffer setObject:mapped forKey:key];
}

- (id)redirectIteration:(id)key {
  return [self.target objectForKey:key];
}

- (void)put:(id)object at:(id)key {
  assert([object isKindOfClass:self.elementClass]);
  [self.target setObject:object forKey:key];
}

- (instancetype)at:(id)key {
  return [self.target objectForKey:key];
}

@end

Collection Constructors

To construct a collection of some class, we send a message to that class with a covariant return type; unfortunately, we cannot decorate instancetype with any further protocols. So, ideally +orderedCollection would return instancetype <OrderedCollection>, but this is currently impossible; thus, you will have to provide the type decoration yourself.³

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

@interface NSObject (Collections)
+ (instancetype)orderedCollection;
+ (instancetype)mapCollection;
@end

@implementation NSObject (Collections)

+ (instancetype)orderedCollection {
  CollectionProxy *proxy = [OrderedCollectionProxy new];
  proxy.elementClass = self;
  return proxy
}

+ (instancetype)mapCollection {
  CollectionProxy *proxy = [MapCollectionProxy new];
  proxy.elementClass = self;
  return proxy;
}

@end

See it in action

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

NSURL <MapCollection> *sites = (id)[NSURL mapCollection];
[sites put:[NSURL URLWithString:@"http://www.jonmsterling.com/"]
        at:@"jon"];
[sites put:[NSURL URLWithString:@"http://www.reddit.com/"]
        at:@"reddit"];
[sites put:[NSURL URLWithString:@"git://github.com/jonsterling/Foam.git"]
        at:"foam_repo"];

NSURL *jonsSite = [sites at:@"jon"];
// => http://www.jonmsterling.com/

NSString <MapCollection> *schemes = (id)sites.scheme.uppercaseString;
/* => { jon: "HTTP://",
        reddit: "HTTP://",
        foam_repo: "GIT://" }
 */

Further Exercises

These HOMs do not correctly handle methods that return non-object types. It is definitely possible to write a more robust version that will box primitives appropriately, but not within the scope of this post. This will require further inspection of the method signature of the forwarded invocation.