Re: [objc-improvements] Warnings when compiling GNUStep

[Ziemowit Laski]

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