I think we're on the same page now. The auto-conversion was my biggest gripe, and adding pointers, although in theory allowed by C, is wrong enough that this won't be used in the literal sense. I am concerned that we'd end up breaking the commutative property for numbers (IE, a+b == b+a), but this can be easily mitigated, and would be a definite win for something like += as an append assignment.
I'd support something that could be done in a way that degrades gracefully with backwards compatibility. Perhaps if there's NSObject class foo and bar. And we want to overload -(void)[doThing:] I can see the following.
-(void) doThing: (NSObject *) ourValue;
-(void) doThingWithFoo: (Foo *) ourValue;
-(void) doThingWithBar: (Bar *) ourValue;
#ifdef OBJ_C_2_1
@overload -doThing:
#endif
Without the extensions, we'd have three messages, obviously. And you can explicitly ask for them by name. Heck, you can even have doThing: do class-checking, and reroute appropriately at runtime as a fallback.
With the extensions, when the compiler comes across doThing: with a known foo as the argument, it'd substitute in the doThingWithFoo:, for instance. This way, there's no mangling needed, binary backwards compatibility is preserved, and debug tools all will be honest about which doThing is being called. The overloading naming can be akin to accessors, where it searches for (message name)As(class) first, then tries (message name)With(class), (message name)Using(class), (message name)(class), (message name)_(class) etc.
Question: suppose we have foo, and bar is a subclass of foo. If foo has a doThingWithFoo:, but bar only has doThing, which would be called when [barObject doThing: fooObject] is used? Would it be the generic but most recently implemented bar's doThing:, or the specialized but not as directly associated foo's doThingWithFoo? I'm leaning towards the former, but I can see arguments for either.
Of course, if you want to explicitly override the type, it'd be a case of bar.fooValue, which moots things in that it's no longer bar being used, but an accessor-generated foo. That works very well.
---
Finally, the issue of operator overloading remains with the non-class core types. I'm not talking about int and float as much as NSPoint, NSSize, NSRect, etc. I could see use in NSSize + NSSize, or NSPoint + NSPoint.
I'm tempted to try this last bit in Obj-C++. Namely, C++ allows for structs to be treated as classes, so I'll try making NSPoint::operator+(NSPoint val) without it declared in the struct definition.
by Blain — Oct 01
I'd support something that could be done in a way that degrades gracefully with backwards compatibility. Perhaps if there's NSObject class foo and bar. And we want to overload -(void)[doThing:] I can see the following.
-(void) doThing: (NSObject *) ourValue; -(void) doThingWithFoo: (Foo *) ourValue; -(void) doThingWithBar: (Bar *) ourValue; #ifdef OBJ_C_2_1 @overload -doThing: #endifWithout the extensions, we'd have three messages, obviously. And you can explicitly ask for them by name. Heck, you can even have doThing: do class-checking, and reroute appropriately at runtime as a fallback.
With the extensions, when the compiler comes across doThing: with a known foo as the argument, it'd substitute in the doThingWithFoo:, for instance. This way, there's no mangling needed, binary backwards compatibility is preserved, and debug tools all will be honest about which doThing is being called. The overloading naming can be akin to accessors, where it searches for (message name)As(class) first, then tries (message name)With(class), (message name)Using(class), (message name)(class), (message name)_(class) etc.
Question: suppose we have foo, and bar is a subclass of foo. If foo has a doThingWithFoo:, but bar only has doThing, which would be called when [barObject doThing: fooObject] is used? Would it be the generic but most recently implemented bar's doThing:, or the specialized but not as directly associated foo's doThingWithFoo? I'm leaning towards the former, but I can see arguments for either.
Of course, if you want to explicitly override the type, it'd be a case of bar.fooValue, which moots things in that it's no longer bar being used, but an accessor-generated foo. That works very well.
---
Finally, the issue of operator overloading remains with the non-class core types. I'm not talking about int and float as much as NSPoint, NSSize, NSRect, etc. I could see use in NSSize + NSSize, or NSPoint + NSPoint.
I'm tempted to try this last bit in Obj-C++. Namely, C++ allows for structs to be treated as classes, so I'll try making NSPoint::operator+(NSPoint val) without it declared in the struct definition.