Not
>>5 here, but all of that and more:
Methods don't have names. They just have named parameters. Instead, the actual name of the function is munged into the first parameter name. So for a method called 'init' that takes 'frame' and 'style', you get:
- (void)initWithFrame:(CGRect)frame style:(SomeEnum)style;
Autorelease pools are a half-decent workaround to the lack of garbage collection, except they make debugging a nightmare. It doesn't capture a stack trace when you autorelease something; instead you just get an exception deep in the implementation of the autorelease pool, off the event thread, and you have no idea what object that even was unless you just happened to be using Instruments at the time to track allocation histories for you.
Exceptions. What a completely broken language feature before garbage collection came around (and it's still not available on iPhone). You basically *have* to autorelease everything as you allocate it in case an exception goes by, but it's incredibly easy to fuck this up. No way to clean up non-memory resources except lots of try/catch blocks (the Java way, of course). And don't even try mixing them with C++; they don't unwind the stack. They just longjmp.
And don't forget, any time you make an autorelease pool, you have to try/catch to release it! Something the docs of course don't tell you; it's apparently good style to leak the whole pool and all of its contents if an exception goes by.
You mean "dereferencing" or "sending a message to"?
Same thing, you're arguing semantics; the pointer would need to be dereferenced to handle a message (because it would need to access some internal state), except that the runtime 'helpfully' detects the nil and skips the method for you. Complete fucking insanity.
This is actually my favorite anti-feature of the language. Have you seen the rules for return values from methods on nil? 0 if it fits in a register or if it's a struct by value that fits entirely in registers, based on the cpu architecture and compiler packing rules. And if it doesn't fit? EAX is a *valid stack pointer* to uninitialized garbage data. Think I'm joking? Go look at the docs. Unbelievable.
how the living fuck do you pass a pointer to a member function?
This actually doesn't bother me. If you interface with C, you have to write function pointer wrappers no matter what language you're using. It's silly to expect Obj-C to provide you this facility. Besides, it's a lot easier to do this in Obj-C than say C++, because in C++ you have to friend the wrapper or make your member callback public; either way you're uglying your interface. In Obj-C at least classes are open, so you can add the callback privately in an implementation file and write a one-line function to call it.
Because then id would be just like void, and that would make even less sense.
So why the fuck isn't it just void? I *hate* that they've stolen 'id' from me; people use that as an identifier fucking everywhere!! Why can't I use it in Obj-C? Could they have picked a worse word to typedef away?
Also, that kind of pointer aliasing is really fucking stupid. Just when the entire rest of the world is finally wising up to strict aliasing and strict typing rules (C99 adding restrict, etc), Obj-C go and fuck it up. It's not possible to build an Obj-C app with strict aliasing.
-Wall complains about that, and with good reason; you practically have to disable that warning if you want to program in Objective C and not go insane.
At work we build with -Wall, and use double parenths around this. It's not so bad; what's bad is when you try to integrate some third-party code which doesn't build with -Wall.
And yes,
>>7, it is a programming practice endorsed by the language designers. Go look at the docs; the idiom is absolutely everywhere in all sample code, in all tutorials and examples. Create a project template in Xcode right now, and you will see single parenths around the init methods. That's bullshit.