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.
That's right, all ObjC messages are bound at runtime but C++ defaults to binding methods at link-time. That said, virtual methods (and ObjC messages) are still type-checked by the compiler. I'm unsure of the details in C++ but in ObjC there is no run-time type checking of parameters.
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?
Firstly, in the model I propose the "button plus button" case would never behave as you suggest simply because the left-hand operand would always stay as the target of the message and never be coerced into any other type. Secondly, I am not proposing any sort of automated type coercion at all. I think that this feature of C++ is the source of many of the problems people have with C++ operator overloading and it makes it very confusing indeed. Operator overloading in languages like Smalltalk, Python and Ruby happily get away without that complexity.
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.
Any automated use of the "-XXXValue" methods leads to exactly the madness of C++ operator overloading that I'm trying to avoid. They are fine when you are trying to present an object in a specific context (e.g. display the value on the slider as a -stringValue but process it as a -doubleValue) but go any deeper than that and you get to just the sort of obfuscation of meaning that Scott was complaining about at the start of this thread.
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.'
If you allow for multiple inheritance and automated type coercion then I agree. In fact what you get is the mess that C++ offers. In Objective C we have simple, linear class inheritance and I'm not proposing to support any coercion. In this case the "best match" is very simple. Just like any other method invocation the parameter has to be a instance of the parameter type or a subtype of that; if there is more than one match then take the match which is closest in the class inheritance chain. So, if I have different methods for a responder, a view or a button then an NSPopUpButton is going to match the button, a generic NSControl is going to match the view, an NSWindow is going to match the responder and an NSDictionary is not going to match anything and raises a warning at compile time, not at run time.
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.
Pose as class will not be a problem, though if you add overloaded operators at run time then the compiler has every right to warn about their use at compile time since they didn't exist then. Categories not only work, but are the "right" way to do this. The classes from the current libraries can have operator overloading support added through categories. Furthermore, if I come up with a new class and I want to add specific support for it as the right-hand operand on some existing class I can retrofit that through a category too. Method swizzling is an ugly hack but it should still work with my envisioned implementation.
by Nicko — Sep 30
That's right, all ObjC messages are bound at runtime but C++ defaults to binding methods at link-time. That said, virtual methods (and ObjC messages) are still type-checked by the compiler. I'm unsure of the details in C++ but in ObjC there is no run-time type checking of parameters.
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?
Firstly, in the model I propose the "button plus button" case would never behave as you suggest simply because the left-hand operand would always stay as the target of the message and never be coerced into any other type. Secondly, I am not proposing any sort of automated type coercion at all. I think that this feature of C++ is the source of many of the problems people have with C++ operator overloading and it makes it very confusing indeed. Operator overloading in languages like Smalltalk, Python and Ruby happily get away without that complexity.
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.
Any automated use of the "-XXXValue" methods leads to exactly the madness of C++ operator overloading that I'm trying to avoid. They are fine when you are trying to present an object in a specific context (e.g. display the value on the slider as a -stringValue but process it as a -doubleValue) but go any deeper than that and you get to just the sort of obfuscation of meaning that Scott was complaining about at the start of this thread.
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.'
If you allow for multiple inheritance and automated type coercion then I agree. In fact what you get is the mess that C++ offers. In Objective C we have simple, linear class inheritance and I'm not proposing to support any coercion. In this case the "best match" is very simple. Just like any other method invocation the parameter has to be a instance of the parameter type or a subtype of that; if there is more than one match then take the match which is closest in the class inheritance chain. So, if I have different methods for a responder, a view or a button then an NSPopUpButton is going to match the button, a generic NSControl is going to match the view, an NSWindow is going to match the responder and an NSDictionary is not going to match anything and raises a warning at compile time, not at run time.
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.
Pose as class will not be a problem, though if you add overloaded operators at run time then the compiler has every right to warn about their use at compile time since they didn't exist then. Categories not only work, but are the "right" way to do this. The classes from the current libraries can have operator overloading support added through categories. Furthermore, if I come up with a new class and I want to add specific support for it as the right-hand operand on some existing class I can retrofit that through a category too. Method swizzling is an ugly hack but it should still work with my envisioned implementation.