🚀 go-pugleaf

In article <1992Jul31.234928.1313@cadsun.corp.mot.com> shang@corp.mot.com writes:
>In article <1992Jul30.171127.18238@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU  
>(John MAX Skaller) writes:
>> 	I do not recall how you proposed to constrain downcasting
>> so it might be detected at compile time (given the function body
>> to whom the parameter is passed is separately compiled).
>>
>Very simple: using RTTC to keep a type safe downcast. If you want to cast an  
>animal to a cat, check whether the animal is actually a cat. If you want to  
>cast an argument of some unknown type T1 to an argument of some unknown type  
>T2, check whether T1 is actually T2. If you do not check, the compiler tells  
>you that your program has a potential error.

	Oh, thats ensure *safety*. It is not the kind of constraint
I was talking about---I assumed it can be done safely. I'm not
interested in how to do it safely, or whether we want to
do it safely. Surely I agree IF we are allowed to downcast
somewhere, we would LIKE to be sure we get the right pointer
back. It is the IF that interests me. 

	I want to constrain downcasting so it is SOUND.

	The type of constraint I'm talking about is a limitation
on what base pointers are *allowed* to be downcast to what
derived classes.

	There is an implicit constraint here: you must know the
name of a derived class to downcast to it.  That means if I want
to stop you downcasting to my class, I can make it anonymous,
for example. I have ACCESS control. But only by not naming my class.

	I do NOT think this constraint is enough.  By enough I
mean something specific: I mean enough to ensure that downcasting
is always SOUND as well as safe.  The syntax

	f(Base[Derived1,Derived2]* b);

was devised by me to demonstrate an additional constraint: in f you are
only allowed to  downcast b, and only to Derived1 or Derived2
(or any base of them).


	[And as it stands the above mechanism is NOT enough to 
ensure soundness. Because it can be trivially circumvented.]
> 
>Your "mate" example is the best one, I don't think it is necessary to make a  
>new one.
>
>    Animal::mate (thiscalss &peer);
>    // you needn't check whether peer is the same type as this object
>    // since the interface ensures that.

	And gives a run-time error if not. The type system is then
no longer statically type safe. At the moment, it is. My thisclass
suggestion did not have this problem. The type check was done under
programmer control.

>
>    Cat c1,c2;
>    Dog d1,d2;
>    Crockdile k1, k2;
>    Lizard z1, z2;
>    Mammal *m1, *m2;
>    Reptile *r1, *r2;
>    Animal *a1, *a2;
>
>    c1.mate(c2);   // okay.
>    c1.mate(d1);   // error detected by compiler

	Oh, yes. True. You are quite correct: when the exact type
is know because a value is used, the compiler can check.
I understand.
>
>    m1 = &d1;
>    a1 = &d2;
>    m1->mate(*a2);  // okay (through type inference)

	Yes, this is harder for the compiler.

[other good examples deleted]

>
>I hope the above example can convince you that the resulting program will be  
>type-error free at run time.

	Yes. Not all cases can be checked though, some must be
deferred to run-time. Then I suppose you get a warning from the
compiler.

	f(animal& a1, animal& a2) { a1.mate(a2); }
	// must be checked at run time

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------