On Jul 11, 2011, at 8:59 PM, Michael Ash wrote:
> On Jul 11, 2011, at 8: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
>
> I believe the intent of Objective-C++ is largely to allow easy bridging between Objective-C and C++ code without having to route everything through C first. Historically there has been little or no effort to actually bridge language features across. With a couple of exceptions, like support for automatically calling C++ constructors and destructors when an ObjC class has C++ objects for ivars, they basically live in their own separate worlds, and ObjC++ just lets you put them into the same file.
I do not disagree with that assertion, but it does reinforce the notion that Objective-C++ is a "second-class citizen" to both Objective-C and C++; on some days I feel that it's 90% one language and 10% the other, due to the gluiness of the languages.
>> In short, I do get the distinct feeling that when people say that "Objective-C++ is a superset of C++ just as much as Objective-C is a superset of C", they are being misled; Objective-C++ really seems like it's defined as the subset of the intersection of two sets rather than a big set that contains two sets.
>
> I'm not sure why this would be misleading. Take Objective-C, remove the "C", add C++, and what you have is exactly what ObjC++ is. It's C++ with the Objective- extensions available. This doesn't imply *any* bridging between the two worlds. C++ features don't apply to the Objective- side, but neither do all C features. You can't do type-based overloading with Objective-C methods, but neither can you get a C function pointer from one.
The problem with the line of thinking that "Objective-C++ is adding Objective- to C++ like adding Objective-C is adding Objective- to C" is that some may interpret that the "Objective" part is tightly wound to C++ as much as it is wound to C, which isn't the case, since that would imply some bridging between the world of C++ and the world of Objective-C.
And a hybrid of Objective-C and C++ should, because it's healthy, have some separation, but not the near-total separation like it is now; both in terms of the language itself and the standard library (the C++ library "extended" the C library, as is Cocoa if you call it the definitive Objective-C library; why can't there be an Objective-C++ standard library extending both?).
> It sounds like you're after a sort of unified language which pulls features from both ends and puts them all together. That would certainly be an interesting experiment, but I don't believe it's what Objective-C++ is intended to be, and that would go well beyond simply putting the Objective-C language extensions on top of C++ instead.
It would be quite interesting, I'd agree. But right now it does seem like the Objective-C world and the C++ world are out to compete rather than cooperate, and if there was more cooperation the whole would be greater than the sum of its parts. I can't see why Objective-C++ can't be that whole; why Objective-C++ can't go beyond simply putting the "Objective" onto a struct as defined in C rather than a struct defined in C++.
It would be nice, for example, to see a hybrid class that can both call methods and receive messages. If an Objective-C class is built upon a C struct, why can't an Objective-C++ class be based on a C++ struct? Why can't I give this "base struct" a custom default constructor so that I can have reference members (not that it's a good idea, but strictly as a "what if"...)? Why is there a clear separation between the C++ virtual method and the Objective-C message handling despite their (outward) similarity? In short, why can't I do something like:
@interface Foo : HypotheticalNSObjectAnalogue {
@protected
class reference {
bool operator==(const reference& rhs) const;
};
@public
reference operator*() const;
}
- (id) init;
@end
...
Foo* a = [[Foo alloc] init];
Foo* b = [[Foo alloc] init];
...
if (*a == *b) { ... }
(Ignore the horribly mangled semantics behind the construction above from the perspective of one language or the other; it's meant to convey the ability to implement an equality-by-value operator C++ style while maintaining message handling Objective-C style all in one class)
I'd gander as this would be what some would interpret "adding Objective to C++" means, or what Objective-C++ should be. Still, I'd take Objective-C++ as it is over using one language exclusively over the other; there has to be something incredibly technical beyond my understanding that makes this vision impossible, rather than just relying on inaction as an excuse (like it had been with Objective-C++03 1.0 and POD C++ type members)... _______________________________________________
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
