I'd rather see that form deprecated for use with Object pointers and attempts to use it will just cause the compiler to warn objClass may not respond to '__add__:' or something of that ilk.
One of my bugaboos (Woohoo! Bugaboos is considered a word!) about C++ is that it's not a perfect superset of C, while Obj-C is. In other words, any C program will compile in Obj-C, while it's possible to make a C program that either won't compile with C++, or will compile differently. This is my major sticking point. As soon as you have to use "Extern C" or similar, you no longer have an upgrade. You have a completely different language.
The other problem becomes the heavy use of @selector and similar items. How do you differentiate between -[add:] taking an int and -[add:] taking a float? How would it be backwards compatible without any special hints?
I also stand by my holding the compiler-defined signs as sacred to Obj-C, but I can see a few compromises. Namely, that not only Obj-C should extend itself while keeping true to the strict C/Smalltalk separation, but that Obj-C++, the fusion of C++ and Obj-C that we already have, should improve and evolve. That is, no operator overloading on .m files, but .mm is fair game.
Not only that, but I can see setting aside a playpen for compiler-defined overrides. Namely, endTime = startTime + delay still plays with pointer math, and isn't the same as endTime = [startTime addTimeInterval: delay]; (Which, I might add, is quite readable). But I could see a use for something like:
endTime = [startTime + delay];
That way, the brackets let the coder and compiler know it's an object message instead of pointer math, but with a twist: like the dot notation, it's syntactic sugar at the compiler level, not the language level. In other words, which message gets called would be dependent on the following variable.
With an int, the compiler would swap in -[addIntValue:]. With a long, the compiler would swap in -[addLongValue:]. And NSObject's -[addLongValue:] would call -[addIntValue:], etc. With an object, it'd be -[addObjectValue:], and so forth. Yes, this wouldn't allow for overloading based on which id. But part of Obj-C's foundations is that it's not the kind of object that matters as much as what it can do; check at runtime for [respondsToSelector:].
Does that sound like a promising idea for Obj-C++ 3.0?
by Blain — Sep 23
One of my bugaboos (Woohoo! Bugaboos is considered a word!) about C++ is that it's not a perfect superset of C, while Obj-C is. In other words, any C program will compile in Obj-C, while it's possible to make a C program that either won't compile with C++, or will compile differently. This is my major sticking point. As soon as you have to use "Extern C" or similar, you no longer have an upgrade. You have a completely different language.
The other problem becomes the heavy use of @selector and similar items. How do you differentiate between -[add:] taking an int and -[add:] taking a float? How would it be backwards compatible without any special hints?
I also stand by my holding the compiler-defined signs as sacred to Obj-C, but I can see a few compromises. Namely, that not only Obj-C should extend itself while keeping true to the strict C/Smalltalk separation, but that Obj-C++, the fusion of C++ and Obj-C that we already have, should improve and evolve. That is, no operator overloading on .m files, but .mm is fair game.
Not only that, but I can see setting aside a playpen for compiler-defined overrides. Namely, endTime = startTime + delay still plays with pointer math, and isn't the same as endTime = [startTime addTimeInterval: delay]; (Which, I might add, is quite readable). But I could see a use for something like:
endTime = [startTime + delay];
That way, the brackets let the coder and compiler know it's an object message instead of pointer math, but with a twist: like the dot notation, it's syntactic sugar at the compiler level, not the language level. In other words, which message gets called would be dependent on the following variable.
With an int, the compiler would swap in -[addIntValue:]. With a long, the compiler would swap in -[addLongValue:]. And NSObject's -[addLongValue:] would call -[addIntValue:], etc. With an object, it'd be -[addObjectValue:], and so forth. Yes, this wouldn't allow for overloading based on which id. But part of Obj-C's foundations is that it's not the kind of object that matters as much as what it can do; check at runtime for [respondsToSelector:].
Does that sound like a promising idea for Obj-C++ 3.0?