Basically this is saying that JWZ, or any other programmer, is as good as the APIs he memorized and has similar shelf life.

The point JWZ is making, and I think most developers past a certain number of years would sympathize with, is that a well designed API should just make sense to a decent developer. It should follow some common sense and accepted conventions that fit your past experience and allow you to figure it out the way travelers find their way around a well designed airport, or a good mechanic approaches a new engine (before software messed these up too..)

Of course it's always possible to just send developers to RTFM in order to do every minor task. If that's the criteria, all APIs are equally great as long as they have some docs, and software developers are not architects or mechanics or chefs, but well paid employees at a fast food franchise, cooking your McMuffin per the updated company manual.

The problem is that JWZ doesn't seem to consider this possibility at all; his seemingly shallow experience with OpenGL is enough for him to assume a position of insight, and his obvious conclusion is that some incompetent buffoon must have been in charge of the API which he does not feel familiar with.

Being great in any field of programming ought to teach you that things are rarely that simple. I simply think that ranting about things which you really aren't that familiar with is a trait that doesn't fit a purported expert in the field — or a purported expert in the field should be able to recognize the things he/she isn't one in.

It's 2010, and we're still innovating on how you pass color components around. Seriously?

Actually, in the first example, the MacOS code looks like the API designed by clueless interns that don't get OO. It's the same classic mistake of passing in an X and a Y instead of a Point Object from the 1st generation Java GUI library. The iPhone code does the right thing. Instead of passing around un-encapsulated data, pass around Objects instead!

    const CGFloat *rgba = CGColorGetComponents([fg CGColor]);
    CGFloat a = rgba[4]; //Crash!

    typedef struct {
        CGFloat r;
        CGFloat g;
        CGFloat b;
        CGFloat a;
    } UIRGBAColor;
    
    //...
    
    UIRGBAColor rgba = [fg rgbaComponents];

In the Point example, the API that respects encapsulation would remain the same between the 2D and 3D versions, along with any code using it. The API with un-encapsulated data would have to change at every single place in the code where a Point was passed.

(In other words, the implementation details of Point have leaked out into the system at perhaps 100's of places. Avoiding this and decoupleing ourselves from implementation is precisely why we have encapsulation in OO.)

How this applies to color is left as an exercise to the student.

This is what I'd like to hear. Cocoa has NSPoint, which is exactly what you're talking about, for points. And NSColor is already a kind of the basic object for colors. Do you really need more primitive types for this?

(Please note that I don't intend to argue, I'm asking for a better solution. Thanks!)

I still don't get the point.