[Top][All Lists]

[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:
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

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;


@interface MutableClass: ImmutableClass

- (NSMutableArray*) allElements;


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

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

@interface Foo
-(NSMutableArray *) method;
@interface Bar : Foo
-(NSArray *) method;

I don't think we warn about it currently, and I don't think warning about it
would be acceptable to Apple (see above).

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

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?

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]