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

[Alexander Malmberg]

Ziemowit Laski wrote:
> On Monday, Sep 8, 2003, at 16:19 US/Pacific, Alexander Malmberg wrote:
> > David Ayers wrote:
> >> Ziemowit Laski wrote:
> >>> On Saturday, Sep 6, 2003, at 00:54 US/Pacific, David Ayers wrote:
[snip]
> > 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.

It is no coincidence that the prototypes differed only slightly, and
only in the type of an object. Of the conflicts the new warnings expose
in GNUstep (and all apps and libraries I've tested, and libFoundation),
all except one are of this type.

> 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. :-)

Note "In this case"; obviously, the results will be different if you
look at a different case. :)

[snip]
> This is a good comparison of the _effect_ of the two approaches.
> However,
> the IMP approach does not attempt to guess

Not true. It guesses that the return type is "id".

> or infer anything from
> anything
> -- IMP is used whenever there are conflicting methods (or no methods),
> period.
> I would argue that this simplicity is a virtue, from the end-users'
> viewpoint. :-)

Picking one "randomly" is also simple (arguably even more simple) from
the user's pov:

If the prototypes don't really conflict, the compiler will do the right
thing. Otherwise, it might break.

I'd rather explain this to a new user than the type promotion rules for
variadic functions.

[snip]
> Theoretical objections aside, can you point me to a specific case in
> actual
> code (in GNUStep or elsewhere) where where the new IMP "behavior" breaks
> "compatibility"?

Yes, eg.:

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

The old code would pick one randomly and get the return type right. The
new code will guess that the return type is id. Of course, on most
systems, this will "just happen" to work anyway. GNUstep runs on many
systems, though. :)

[snip]
> >> :-) but this protoype is not just a conflicting prototype, it's an
> >> outright incompatible prototype, and as I believe Steve Naroff already
> >> suggested, it may be wiser to emit a hard error
> >
> > I disagree. A warning and almost any behavior is better than a hard
> > error.
> 
> Only if you're an expert user (the joke about the car designed by UNIX
> gurus comes
> to mind).  If you're a developer learning Objective-C, you'll either
> ignore the
> warnings at your peril, or file bugs about mysterious errors and
> warnings produced
> by the compiler.

The same could be argued about many of the warnings issued for normal c.
Fortunately, gcc already supports this behavior: just give it the
-Werror option.

- Alexander Malmberg