Path: utzoo!attcan!uunet!decwrl!wuarchive!swbatl!gilstrap
From: gilstrap@swbatl.sbc.com (Brian Gilstrap - UCI - 5-3929)
Newsgroups: comp.object
Subject: Re: inheritance and `type loss'
Message-ID: <1990Jul11.184517.16505@swbatl.sbc.com>
Date: 11 Jul 90 18:45:17 GMT
References: <SRA.90Jul10155606@alonzo.ecs.soton.ac.uk> <1130012@gore.com>
Reply-To: gilstrap@swbatl.UUCP (Brian Gilstrap - UCI - 5-3929)
Organization: Southwestern Bell Tele. Co. - Advanced Technology Lab - St. Louis
Lines: 45

Jacob Gore's comments have one '>'
Stephen Adams' have two '>'s

[1]
>>(a) what should   (V+V).image  yield?  "10" or "X"?
>"X", because a roman + a roman -> a roman

[2]
>> 		   (V+1).image          "6" or "VI"?
>"VI", because a roman + an integer -> a roman
>Why?  A roman is an integer, so any place an integer can be used, a roman
>can be used just as well.  Thus, "a roman + an integer" automatically gets
>the type of "a roman + a roman".

This statement doesn't make sense to me.  (IMHO) What's really going on here is
simply a precedence rule: "In a binary operator, if the second argument can
be converted to the same type/class as that of the first, then use the type
of the first argument as the default result type."

[3]
>>		   (1+V).image          "6" or "VI" or error (in +)?
>"6", according to your definition of +.  Not an error because V is a roman
>and hence an integer, and + is defined for two integers.

Again, the same precedence rule.

I could easily see a language where the default was

	convert the Roman to an Integer no matter if it's first or second
	(least common denominator)

OR
	convert the Integer to an Roman no matter if it's first or second
	(I guess you could call this "specialization of results")

Just because C++ approaches things the way described above doesn't mean it
has to be that way.

By the way, this isn't meant to be flammage.  Please correct me if I've
missed something.

Brian R. Gilstrap
gilstrap@swbatl.sbc.com
gilstrap@swbatl.uucp
...!{texbell,uunet}!swbatl!gilstrap