Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!shadooby!accuvax.nwu.edu!nucsrl!gore!jacob
From: jacob@gore.com (Jacob Gore)
Newsgroups: comp.sys.next
Subject: Re: Deferred methods and strong typing
Message-ID: <130012@gore.com>
Date: 9 Jul 89 07:42:18 GMT
References: <130007@gore.com>
Reply-To: jacob@gore.com (Jacob Gore)
Organization: Gore Enterprises
Lines: 38

/ comp.sys.next / dml@esl.UUCP (Denis Lynch) / Jul  7, 1989 /
> Isn't it true that the warning is generated because of the *declaration* of
> someMethod, not its use? (Of course the run-time problem happens because of
> the use).

Yes, but the two problems are related: because (B*) is not recognized as a
subtype of (A*), the method in class B is treated as an alternative to the
one in class A, instead of being treated as its replacement (for instances
of B and of its subclasses).

> This seems to be pretty much required because of the *possibility* of
> dynamic binding: the compiler needs to be able to figure out what someMethod
> will return under any circumstances, especially since common usage is to
> type everything as id.

But subtyping is implemented correctly in at least some cases.  For
example, you can do:

	@implementation B:A
	...
	(A*)someMethod {
		...
		return self;
	}

Even though the return value is of type (B*), it is (correctly) understood
to match the declared return type, (A*).

So it doesn't look like a language problem (I was worried for a while that
the concept of subtyping was omitted altogether, and was quite relieved to
find out otherwise), but just a compiler bug.

Does the Stepstone compiler exhibit the same problem, or is it limited to
the 0.9 version of NeXT's compiler?  (If I understand the docs correctly,
they are no longer the same beast.)

--
Jacob Gore	Jacob@Gore.Com		{nucsrl,boulder}!gore!jacob