Ideas for improving the Objective-C language

This semi-rant is about how Objective-C contains a lot of unnecessary code and some various not-thought-out-too-well ideas on how I would change it. Sorry about the lack of syntax highlighting, and poor design of this web site. Scroll to the bottom of the full post to see the immediate effect of these ideas).

Win32 API code woes

1. No function calls deal with floating point variables, everything is always integers or fixed-point. This would be especially useful in GDI functions such as font instance creation.


2. Many function calls take optional parameters that are hardly used (think CreateFile).


3. Constants used as parameters are always in uppercase, words separated by underscores. Consistent, but not always easy to read when your function names are always just upper-camel-case.


4. No clear indication or naming convention that dictates ownership of returned objects.


5. Very, very few API functions allocate space on the calling process' heap. Instead, you must call the same function twice, once to get the required size, then again with a valid pointer allocated to the size returned by the first call.


6. Functions that deal with strings have two versions (made transparent by a massive amount of #defines). One version takes the equivalent of (char *), the other takes the equivalent of (unsigned short *). This is an issue where string management is done at application level rather than operating system level (Carbon and Cocoa for Mac OS X both have string types that deal with multiple encodings).


7. Inconsistent enumeration functions. Some functions enumerate objects by the two-function-first-to-get-size-second-to-get-data method, whereas other functions enumerate objects by taking a callback function as a parameter (EnumPrinters vs EnumWindows). Some enumerate by subsequent calls to the same function (FindNextFile).

What would have been better?

1. Even though floating-point coprocessors were not terribly common back when Windows first started, they are certainly common now. Old fixed-point functions should have been deprecated so that GDI and other things could have taken advantage of the FP coprocessor.


2. CreateFile (not the only one) takes a lot of useless parameters that are almost always set to NULL or 0. Since this particular function returns a handle, it would have been better to make the CreateFile call simpler and offer other functions to manipulate the handle to behave differently if required.


3. Although a consistent constant naming style is great, it sucks when it impairs legibility. In Carbon on Mac OS X, constants are preceded with a &lquot;k&rquot; and the constant names are suffixed in upper camel-case.


4. With any decent API, the function name indicates the ownership of returned objects. With Win32 API, MSDN is where you go to find out.


5. Functions should allocate space on the heap if necessary instead of forcing two function calls.


6. Windows should have declared a string object, even if it is an opaque type, purely so they could have implemented a proper layer. Instead of the char and ushort versions, they could have left the char versions deprecated and remapped the char versions to the OS-String defined versions, then multiple encodings could have been natively supported within the same application much more easily.


7. All enumeration functions should be consistent. Always use callbacks, or always use double-calls, or always use subsequent-calling.