[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [objc-improvements] Warnings when compiling GNUStep
From: |
Ziemowit Laski |
Subject: |
Re: [objc-improvements] Warnings when compiling GNUStep |
Date: |
Wed, 3 Sep 2003 18:05:44 -0700 |
On Wednesday, Sep 3, 2003, at 17:35 US/Pacific, Alexander Malmberg
wrote:
Ziemowit Laski wrote:
On Wednesday, Sep 3, 2003, at 13:37 US/Pacific, Dirk Theisen wrote:
[snip]
You are touching a spot I long wish ObjC had it:
Covariant return types. Those are absolutely valid and I think you
know that. If not, I can dig up the relevant (oldish) papers. This
would give ObjC a little bit more expressive power in some cases and
another advantage over Java.
Covariant return types (unlike covariant arguments :-) ) are valid in
an OO-theoretic sense,
Why not arguments? As far as I can tell, this applies to arguments as
well, but the "other way". Ie. for return types a subclass can specify
a
more specific type, while for arguments, a subclass can specify a more
generic type.
...which would make them contravariant, not covariant. :-)
but I'm not sure how well they it in with
_existing_ Objective-C usage.
My patch would warn if this happens, and it has not warned about
anything that in GNUstep that I've tested with. This implies that it's
not very common (at least not in our code).
For example, how should the compiler deal with invariant, unrelated or
contra-variant return types?
The same way that it deals with conflicting prototypes. To accept this,
we just need to change our rules for when prototypes conflict with each
other.
Currently, the compiler only cares about conflicting prototypes when
dispatching to 'id'/'Class', and under no other circumstances.
What I want is to declare:
@interface ImmutableClass: NSObject
- (NSArray*) allElements;
@end
@interface MutableClass: ImmutableClass
- (NSMutableArray*) allElements;
@end
You can declare that today, without prejudice (or warnings).
But only because the compiler doesn't check prototypes properly. My
patch fixes that, and it would (definitely correctly) find both
prototypes, and (not necessarily correctly in this case) issue a
warning.
Personally, I like this idea, but it has been shot down within Apple.
I suppose you can enable it only if !flag_next_runtime.
I've cleaned up the prototype searching code, so if we can agree on
suitable (ie. reasonably easy to implement) rules for this, I could
have
a go at implementing it after the current patch is done. Doing it
properly is an option, but it'd take a bit of work. As always,
protocols
and categories make it hairy. :) Also, it's important that we still
warn
about:
@interface Foo
-(NSMutableArray *) method;
@end
@interface Bar : Foo
-(NSArray *) method;
@end
I don't think we warn about it currently, and I don't think warning
about it
would be acceptable to Apple (see above).
The
problem arises if you're sending an 'allElements' message to 'id',
which takes us back to the ongoing discussion on discuss-gnustep. :-)
The covariant checks would only apply when looking for prototypes for
the receiver's type. When the receiver is not known to implement the
method, we'd ignore any covariance and do a normal check of all known
prototypes.
But when you have a receiver type to work with (i.e., it is _not_ an
'id' or
'Class'), then you simply pick the closest ("derived-most") method
signature
and stop. You never get multiply defined warnings when the receiver
type
is known.
I guess I'm not sure what the covariant return type checking is
supposed to
accomplish in this context...
Anyway, see my next e-mail about my proposed, uh, "compromise" regarding
method signature selection. :-)
(BTW, I have contacted "the proper authorities" on setting up an
Apple-hosted ObjC mailing list; please stay tuned.)
Would this be for generic objective-c discussion?
Yes.
--------------------------------------------------------------
Ziemowit Laski 1 Infinite Loop, MS 301-2K
Mac OS X Compiler Group Cupertino, CA USA 95014-2083
Apple Computer, Inc. +1.408.974.6229 Fax .5477
- [objc-improvements] Warnings when compiling GNUStep, Ziemowit Laski, 2003/09/02
- Re: [objc-improvements] Warnings when compiling GNUStep, Ziemowit Laski, 2003/09/03
- Re: [objc-improvements] Warnings when compiling GNUStep, Alexander Malmberg, 2003/09/03
- Re: [objc-improvements] Warnings when compiling GNUStep,
Ziemowit Laski <=
- Re: [objc-improvements] Warnings when compiling GNUStep, Riccardo Mottola, 2003/09/04
- Re: [objc-improvements] Warnings when compiling GNUStep, Alexander Malmberg, 2003/09/04
- Re: [objc-improvements] Warnings when compiling GNUStep, Ziemowit Laski, 2003/09/04
- Re: [objc-improvements] Warnings when compiling GNUStep, Alexander Malmberg, 2003/09/04
- Re: [objc-improvements] Warnings when compiling GNUStep, Ziemowit Laski, 2003/09/04
- Re: [objc-improvements] Warnings when compiling GNUStep, Nicola Pero, 2003/09/05