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.
This is simply untrue. Consider the following code:
Perhaps I should qualify my statement. While the compiler and IDE do know of the classes, especially for things like autocomplete, it doesn't necessarily need to know where specific values and functions are. Or even if they'll be the same.
Correct me if I'm wrong, but C++ has two ways for member functions. The lesser used is a virtual function, which is akin to Obj-C's messages, in that which code is run is determined at runtime. The default, however, is statically bound at compile time based on the variable class. This allows for very fast execution, but can lead to fragile base classes, because a subclass can't redefine a non-virtual function.
The problem is that I think one major advantage of Obj-C is delegates and other informal protocols. But they require virtual functions at every step of the way. But I digress.
If we are going to have some sort of operator overloading then, to satisfy exactly the sort of polymorphic behaviour that you were describing, you want to be able to attempt to pass any class as the operand.
To a degree, yes. For what I focus on, math is actually very low, as I focus more on classes that depend on things like tableView:objectValueForTableColumn:row:, which really could be almost any class. I mention -stringValue below, which also can lead to overloading confusion. If you can add two strings (concatenate), and you can treat an NSButton as a string using -stringValue and -setStringValue, can you add two buttons?
We have a choice here; we can just require ever implementation of every operator to contain some sort of switch code to find the right behviour, we can define some sort of class hierarchy based run-time matching to find a 'best match' message name or we can do that same sort of matching and perform as much of that matching as possible at compile time.
Now that I think of it, take a look at the value methods. They're a good example, in some ways. Both NSCell and NSNumber implement -stringValue, -compare:, intValue, -floatValue, -doubleValue, and the like. They're Obj-C's current response to operator overloading, in two ways. First, the two classes are unrelated save at NSObject, yet they receive the same messages. The second thing, however, is when you hook things up in the nib, there's no mention of it being an int, float, or string. This is a detail done at runtime, effectively overloading the operand as well.
I still bristle at the term "best match," as it always gives me an image of a compiler playing 'pin the tail on the donkey.' But I'm curious as to your solution. I still suggest that it'd be best to extend Obj-C++, which still needs better C++/Obj-C inter-operability and already has some precedent for operator overloading, than to modify Obj-C itself.
The real acid test is if it will still allow for -poseAsClass, categories added at runtime via loaded bundles, and method swizzling. And as much as we disagree over operator overloading, I will gladly be one of the first to download and take your improved compiler for a spin.
by Blain — Sep 23
This is simply untrue. Consider the following code:
Perhaps I should qualify my statement. While the compiler and IDE do know of the classes, especially for things like autocomplete, it doesn't necessarily need to know where specific values and functions are. Or even if they'll be the same.
Correct me if I'm wrong, but C++ has two ways for member functions. The lesser used is a virtual function, which is akin to Obj-C's messages, in that which code is run is determined at runtime. The default, however, is statically bound at compile time based on the variable class. This allows for very fast execution, but can lead to fragile base classes, because a subclass can't redefine a non-virtual function.
The problem is that I think one major advantage of Obj-C is delegates and other informal protocols. But they require virtual functions at every step of the way. But I digress.
If we are going to have some sort of operator overloading then, to satisfy exactly the sort of polymorphic behaviour that you were describing, you want to be able to attempt to pass any class as the operand.
To a degree, yes. For what I focus on, math is actually very low, as I focus more on classes that depend on things like tableView:objectValueForTableColumn:row:, which really could be almost any class. I mention -stringValue below, which also can lead to overloading confusion. If you can add two strings (concatenate), and you can treat an NSButton as a string using -stringValue and -setStringValue, can you add two buttons?
We have a choice here; we can just require ever implementation of every operator to contain some sort of switch code to find the right behviour, we can define some sort of class hierarchy based run-time matching to find a 'best match' message name or we can do that same sort of matching and perform as much of that matching as possible at compile time.
Now that I think of it, take a look at the value methods. They're a good example, in some ways. Both NSCell and NSNumber implement -stringValue, -compare:, intValue, -floatValue, -doubleValue, and the like. They're Obj-C's current response to operator overloading, in two ways. First, the two classes are unrelated save at NSObject, yet they receive the same messages. The second thing, however, is when you hook things up in the nib, there's no mention of it being an int, float, or string. This is a detail done at runtime, effectively overloading the operand as well.
I still bristle at the term "best match," as it always gives me an image of a compiler playing 'pin the tail on the donkey.' But I'm curious as to your solution. I still suggest that it'd be best to extend Obj-C++, which still needs better C++/Obj-C inter-operability and already has some precedent for operator overloading, than to modify Obj-C itself.
The real acid test is if it will still allow for -poseAsClass, categories added at runtime via loaded bundles, and method swizzling. And as much as we disagree over operator overloading, I will gladly be one of the first to download and take your improved compiler for a spin.