>>9
I didn't want to make an extra long post, so skipping the quotes kept it short enough. It's pretty easy to figure out what's going on, though.
Yeah, that "message to
nil does nothing" thing really makes no sense.
What do you mean by "not prototyping it in full"? Do you mean defining functions inside a class definition, the latter being in a compiling unit instead of a header? Because it's not the same thing as omitting the
@interface of an ObjC class, you know. Anyway, if you define an empty
@interface, the warnings will go away -- you can even define a macro to define the empty interface
@interface and begin an
@implementation at the same time, so that you don't have to write the class name twice.
The thing is, those labels are not argument names, they're part of the
method's name, so rearranging
doStuff:with:and: is really pointless.
Whatever, that idiom is really only used in object initialization, so you know where to expect it. Also, I believe you can have the compiler issue warnings for that, so you'll know where the shit may be spilling from.
That's a very messy and hard-to-remember line of code in comparison with the C++-style &foo::bar
It's a simple method call, how hard to remember can it be? Or do you fear you won't remember it because you'll rarely have to use it?
and you're also conveniently ignoring the fact that it takes more than that line to properly call a member function.
Well, of course it does. One line to get the funcion, one line to call the function. Why would you want less?
Man, I don't know how you can whine about such minor issues and be happy with the huge convoluted messes that are C++ and the code it's users generate. Well, to each their own, I guess.