actually, the kAudioHardwarePropertyBootChimeVolumeRangeDecibels-type constants are part of a C interface. i'm not sure if there was an objective-C-style interface.
i used objective C for a number of years, and i came away with the opinion that it had initially been quite a neat little (operative word) hack to give some dynamic binding and a bit of structure to C, but it had turned into something of a monster. its main problem was lack of modularity - all object methods lived in the same namespace, and since there were many of them, huge names were necessitated. the fix for this was to put in place a some more conventional static class-based typechecking, which was a big mistake in my view, because one of the nice things about the early objective-C was freedom of implementation - if you implemented the right methods, then it didn't matter what class (if any) you inherited from. in the end objective C suffers from the same flawed inheritance design as most of the other "object oriented" languages. interfaces are usually designed by extension rather than by use, so one has to spend much time writing silly little pieces of non-code to try to mesh what one would like to do with the design of the interface. the result is often a tangle of interwoven dependencies that is difficult to understand, harder to maintain, and almost impossible to refactor. for something with a stated aim of encouraging software reuse, this style of OO certainly does a good job of actively discouraging it! in contrast i've found Limbo's statically typed (but dynamically implemented) module structure to be excellent for reuse. if objective C had gone more wholeheartedly down the protocol route, it might have ended up with something a bit more like this.
