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