Re: [objc-improvements] Warnings when compiling GNUStep

[Alexander Malmberg]

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.

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

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

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

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

> (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?

- Alexander Malmberg