On Jul 11, 2011, at 5:23 PM, Kelvin Chung wrote:
>> No. The root of the issue here is that you seem to be expecting that in Objective-C++ mode that the two languages are trying to be at parity with each other. It is better to think of the two languages as coexisting, not being tightly integrated or competing for features.
>
> That I do, as I stated in the OP (with regards to "a language unto itself" as opposed to a "glue language"). I'd also like to think that, and correct me if I am wrong, that "just coexisting" makes Objective-C++ as a whole a bit less than the sum of its parts, and making it feel like a "second-rate afterthought" and "generally undesirable", which may have been the intent. Yet, for me I'd prefer using Objective-C++ over using Objective-C or C++ by itself, again for reasons that I'll keep to myself.
>
> Obviously, there's stuff that would be outside of the concern of the language, such as making the libraries work with each other (since after all they are in entirely Objective-C or C++), but it does feel that the combination can be much more, such as namespaced Objective-C classes, overloading selectors, one bool type rather than two or three, one null pointer constant rather than "a lot", one foreach rather than two, one try/catch rather than two, one lambda expression rather than two, etc.
No, there's no desire to make Objective-C++ deliberately unpalatable. Most of these concerns boil down to one of these:
* Historical accident that's hard to change now. nil vs NULL vs nullptr and bool vs BOOL fall into this category. Changing the definition of nil is a compatibility risk for precisely the same reasons that the C++ committee added nullptr instead of fixing NULL. We might be able to get away with making nil identical to nullptr, but it's not something to do lightly. Same with bool and BOOL.
* Semantic differences. try/catch vs @try/@catch and lambda vs block object fall into this category. The C++ and the Objective-C constructs mean different things, so you can't simply smash them together somehow. If you go back to the basics, @interface vs class fits here too. When Objective-C and C++ features collide, we generally leave them separate but equal. We don't want to force a square feature into a round hole, and we don't want to fall back to some lowest common denominator solution.
* Technical difficulty. Selector overloading is one of these. Objective-C code frequently looks up methods by name. Such code would need to be changed to deal with whatever type descriptor or name mangling you introduce to disambiguate methods with the same name but different types.
--
Greg Parker email@hidden Runtime Wrangler
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Objc-language mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
