Re: [objc-improvements] Just remembered something about multiplemethod signatures...

[Nicola Pero]

> >>>> Given
> >>>> Class1: -(id)test1Float:(float)f int:(int)i;
> >>>> Class2: -(Object *)test1Float:(float)f int:(int)i;
> >>>>
> >>>> In the old case, you could get a warning about the compiler picking
> >>>> the wrong prototype but the results were correct.
> >>>
> >>> In this particular case, the compiler picked a method signature out of
> >>> a hat that happened to work in that the intended codegen occurred.
> >
> > In this case, it didn't just "happen to work".
> 
> Sure it did.  You just happened to have two signatures that didn't 
> differ by that much.
> Throw in
> 
>     -(double)test1Float:(int)f int:(float)i;
>     -(void)test1Float:(float)f int:(int)i;
>     -(struct foo)test1Float:(struct bar)f int:(int)i;
> 
> and now tell me that it still happens to work. :-)

But how likely it is that a method called 'test1Float:int:' actually takes
an int (or structure) as first argument and a float as second argument ?  
:-)

Of course a method called 'test1Float:int:' takes a float as first
argument and an int as second argument.

And it is *not* a chance.

To evaluate the different error recovery strategies, the best way seems to
me to evaluate/benchmark them on some real world testcases.

For example, some time ago Alex posted the list of warnings about
conflicting prototypes generated by using his patch on GNUstep.  That is a
great practical test bench for any algorithm to solve the conflicts.

I've collected at the end of this email the list of all conflicting
prototypes reported.

So now we can get pragmatic/real - please note that *ALL* conflicting
prototypes but one are due to objects being mistyped (such as id versus
NSObject *, or NSMenuItem * versus id<NSMenuItem> or similar stuff).  

They can *all* be compiled by the compiler correctly if only the fall-back
strategy is sane (such as the traditional one!) - the 'conflicting'
prototypes actually generate all the same code, and only differ in objects
being slightly miscast.

The only conflicting prototype not due to mistyped objects is the first
one, where the old/obsolete Object root class uses -error:  with a (const
char *) argument, and which can be explained by the fact that the
old/obsolete Object root class used a different set of conventions.

So, the existing 'pick up the first found prototype' strategy would
compile all conflicting prototypes in GNUstep correctly, except one
(-error:).

How well would your 'IMP fallback' strategy work in practice ?  How many
of these conflicting prototypes would it compile correctly ?

What about yourself gathering practical examples of conflicting prototypes
from the Apple source code too and evaluating how well the various
error-recovery strategies work on these practical examples ?

There is no point in discussing in abstract what happens if
'test1Float:int:' actually takes an 'int' as first argument and a 'float'
as second argument.  What we really want is the compiler to always warn
when there are conflicting prototypes, and then to follow a
fall-back/recovery strategy which works reasonably well *in the real
world*, such as when compiling my GNUstep code or when compiling your
Apple frameworks. :-)


Conflicting prototypes found by Alex while compiling GNUstep -


-(void)error:(NSString *)e
-error:(const char *)aString, ...


-(id)objectForKey:(id)aKey
-(id)objectForKey:(NSString *)defaultName


-(NSPortCoder *)_getReplyRmc:(int)sn
-_getReplyRmc:(int)sn


-(NSComparisonResult)compare:(NSDate *)otherDate
-(NSComparisonResult)compare:(id)anObject


-(NSComparisonResult)compare:(NSNumber *)decimalNumber
-(NSComparisonResult)compare:(id)anObject


-(void)addObserver:(id)anObserver 
          selector:(SEL)aSelector
              name:(NSString *)notificationName 
            object:(NSString *)anObject

-(void)addObserver:(id)observer
          selector:(SEL)selector 
              name:(NSString *)name
            object:(id)object


-(void)postNotificationName:(NSString *)notificationName
                     object:(NSString *)anObject

-(void)postNotificationName:(NSString *)name
                     object:(id)object



-(void)postNotificationName:(NSString *)notificationName
                     object:(NSString *)anObject
                   userInfo:(NSDictionary *)userInfo

-(void)postNotificationName:(NSString *)name
                     object:(id)object
                   userInfo:(NSDictionary *)info


-(void)removeObserver:(id)anObserver
                 name:(NSString *)notificationName
               object:(NSString *)anObject

-(void)removeObserver:(id)observer
                 name:(NSString *)name
               object:(id)object


-(NSComparisonResult)compare:(NSString *)aString
-(NSComparisonResult)compare:(id)anObject


-(id)initWithPath:(NSString *)path
-(NSDistributedLock *)initWithPath:(NSString *)aPath


-(id)target
-(NSObject *)target


-(NSMutableDictionary *)_nonAutoreleasedTypingAttributes
-(NSDictionary *)_nonAutoreleasedTypingAttributes


-(void)insertText:(id)aString
-(void)insertText:(NSString *)aString


-(BOOL)validateMenuItem:(id <NSMenuItem>)menuItem
-(BOOL)validateMenuItem:(NSMenuItem *)aMenuItem


+(NSOpenGLContext *)currentContext
+(NSGraphicsContext *)currentContext


-(void)browser:(id)sender
createRowsForColumn:(int)column
      inMatrix:(NSMatrix *)matrix

-(void)browser:(NSBrowser *)sender 
createRowsForColumn:(int)column
      inMatrix:(NSMatrix *)matrix


-(id)setUpFieldEditorAttributes:(NSText *)textObject
-(NSText *)setUpFieldEditorAttributes:(NSText *)textObject


-(NSClipView *)contentView
-(id)contentView


-(id)initWithIdentifier:(id)anObject
-(id)initWithIdentifier:(NSString *)identifier


-(id)identifier
-(NSString *)identifier