Re: [9fans] new compilers

[rog@vitanuova.com]

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.