I think what we're butting heads up against is a philosophical difference in how C++ treats objects and Obj-C treats them. Obj-C is strongly typed in a way, in that there's only one object structure, the id. Everything else is on top of it, in terms of data and methods. Because of this, you don't need to know the class to use an obj-c object. There is no clarification necessary.
Not only does this compile and run, but I didn't even get a warning. Obj-C is already context-sensitive. It's a language arch deluxe, keeping the hot side hot, and the cold side cold. The smalltalk side is completely different than the C side, in class declaration, in class definition, in calling, etc. The difference is that the context (object vs void *) is delineated by the brackets, not by the type that it might or might not be.
This is the crux of the matter: the compiler does not know the class it's being passed -- it doesn't need to; the structure it cares about is constant. A lot of Obj-C's magic uses this. Obj-C doesn't have multiple inheritance, simply because it uses protocols, both formal and informal, instead.
- (void)setDelegate:(id)anObject;
You'll find this in many NSObjects, even ones that aren't directly related. It takes an id. Not even an NSObject. There is not even a shred of a clue what class it's going to be, or even if it stays the same class over time. But it doesn't need to. As long as you check with respondsToSelector:, you're fine. That's right, the compiler need not even know what functions the class has. This is the difference. We don't care about your class, as long as you do your duty.
As for SEL and IMP, do look at methodForSelector:. We already can have the caching technique and eat it, too. And we don't have to sacrifice dynamicness for it. Let us go on without premature optimization.
by Blain — Sep 23
void * testy = [NSString stringWithString:@"Hello, world!"];
NSLog(testy);
Not only does this compile and run, but I didn't even get a warning. Obj-C is already context-sensitive. It's a language arch deluxe, keeping the hot side hot, and the cold side cold. The smalltalk side is completely different than the C side, in class declaration, in class definition, in calling, etc. The difference is that the context (object vs void *) is delineated by the brackets, not by the type that it might or might not be.
This is the crux of the matter: the compiler does not know the class it's being passed -- it doesn't need to; the structure it cares about is constant. A lot of Obj-C's magic uses this. Obj-C doesn't have multiple inheritance, simply because it uses protocols, both formal and informal, instead.
- (void)setDelegate:(id)anObject;
You'll find this in many NSObjects, even ones that aren't directly related. It takes an id. Not even an NSObject. There is not even a shred of a clue what class it's going to be, or even if it stays the same class over time. But it doesn't need to. As long as you check with respondsToSelector:, you're fine. That's right, the compiler need not even know what functions the class has. This is the difference. We don't care about your class, as long as you do your duty.
As for SEL and IMP, do look at methodForSelector:. We already can have the caching technique and eat it, too. And we don't have to sacrifice dynamicness for it. Let us go on without premature optimization.