>>7
Good job writing a post that makes no fucking sense, unless you read it in parallel with
>>5.
"Sending a message to", whatever. In C++ this involves a dereference. I don't know how ObjC implements things under the hood but it really could shit a brick, or at the
very least print something out that can be trapped within a debugger so that these sorts of things can be tracked down
before they blow up in your face 500 lines later. The sooner you can identify a problem, the better.
Yes you can, as long as it's defined before it's used.
Ah. Never mind. My mistake, I usually use -Werror. (As it's the only way I can catch that parameter-rearranging nonsense)
Still, bringing up even a warning for something like that -- at least, unless you're specifically requesting warnings for such pedantry -- is pretty annoying. C++ surely doesn't warn you about defining a class without prototyping it in full.
Why would ObjC be any different
Because people have had better ideas since Smalltalk was invented. Even Visual Basic has rearrangeable named args for fuck's sake.
not a problem of the language
I fully characterize problems of the userbase of a language as a subcategory of problems of the language itself. This only fails to be true if you live in a vacuum. In the Real World you have to work with other people's code.
And that's not just "one line of code". That's a very messy and hard-to-remember line of code in comparison with the C++-style
&foo::bar (which works much the same way as passing around
any other pointer) -- and you're also conveniently ignoring the fact that it takes more than that line to properly call a member function. Of course in either language the only sane and portable way to call a member function if from a wrapper, but it's certainly convenient to be able to cast to a function type with
void * as the first arg (i.e.
this) on supporting systems.