Re: Static typechecking in OO

"oliverhunt@gmail.com" <oliverhunt@gmail.com>
28 May 2007 23:09:09 -0700

          From comp.compilers

Related articles
Strong Types ? hossein.rohani@gmail.com (gygulance) (2007-04-26)
Staic typechecking in OO [was Re: Strong Types ?] Sebastian.Kaliszewski@softax.pl (Sebastian Kaliszewski) (2007-05-04)
Re: Static typechecking in OO [was Re: Strong Types ?] oliverhunt@gmail.com (oliverhunt@gmail.com) (2007-05-06)
Re: Static typechecking in OO [was Re: Strong Types ?] Sebastian.Kaliszewski@softax.pl (Sebastian Kaliszewski) (2007-05-14)
Re: Static typechecking in OO [was Re: Strong Types ?] oliverhunt@gmail.com (oliverhunt@gmail.com) (2007-05-16)
Re: Static typechecking in OO bobduff@shell01.TheWorld.com (Robert A Duff) (2007-05-18)
Re: Static typechecking in OO oliverhunt@gmail.com (oliverhunt@gmail.com) (2007-05-28)
| List of all articles for this month |

From: "oliverhunt@gmail.com" <oliverhunt@gmail.com>
Newsgroups: comp.compilers
Date: 28 May 2007 23:09:09 -0700
Organization: Compilers Central
References: 07-04-12307-05-011 07-05-021 07-05-054 07-05-060 07-05-065
Keywords: types
Posted-Date: 30 May 2007 00:21:57 EDT

On May 17, 9:29 pm, Robert A Duff <bobd...@shell01.TheWorld.com>
wrote:
> ...
> case Type_Of (X) of
> when Expression =>
> ... downcast X to Expression ...
> when No_Expression =>
> ... downcast X to No_Expression ...
> end case;
> ...
> but not:
>
> case Type_Of (X) of
> when Binary_Op =>
> ... downcast X to Binary_Op ...
> when Unary_Op =>
> ... downcast X to Unary_Op ...
> when No_Expression =>
> ... downcast X to No_Expression ...
> end case;
> ...
> - Bob


This is actually similar to the syntax for extracting members from
Haskell data types.


But first up, i need to apologise. Having read through a number of my
comments i managed to repeatedly confuse runtime dispatch with runtime
typing -- this is partially caused by my initial misunderstanding of
Sebastian's original suggestion. So i apologise for a few of my
incorrect statements. I also feel i should apologise to Sebastian.


>From the Sebastian's original example
>void do_special_thing(virtual my_derived_1 &d1) { d1.foo(); }
>void do_special_thing(virtual my_derived_2 &d2) { d2.bar(); }
>
>for(polimorphic_container<my_base_class>::iterator i = my_container.begin();
> i != my_container.end();
> ++i)
>{
> do_special_thing(*i);
>}
I had assumed there wouldn't be an implementation of
do_special_thing(my_base_class), from which i assumed there was a
guarantee that do_special_thing was not defined over all types.


If there is a requirement that there is an implementation of one of
these methods that covers the base
classes of all virtual parameters, then the function is safe, and the
entire thing is statically verifiable. When I initially realised that
i was being clueless i thought that this was equivalent to standard C+
+/Java virtual methods, however such a scheme would allow multiple
virtual parameters, whereas (in effect) C++/Java/etc allow only one
("this"). Once again apologies to Sebastian.


However, i still assert that you can't statically verify any OO
language that allows downcasting. That said it is clear that i need
to be more specific, so here we go.


No unchecked cast can be statically verified. I think however the
standard definition of a cast implies an absence of such checking.
Something similar to Bob's case-type semantic could be considered a
checked cast, but equally we consider it to be a form of virtual
dispatch. Take for example:
class A { doAStuff(); };
class B : A { doBStuff(); };
class C : A { doCStuff(); };


A expr = magic;


case TypeOf(expr) of
    when B:
        expr.doBStuff(); // No cast necessary as the compiler knows that
expr must be of type B here
    otherwise:
        expr.doAStuff();


I would see this as being a form of (effectively-)virtual dispatch
rather than a cast, but if we compared to the equivalent java-esque
you could probably argue that it's a cast:


A expr = magic;
if (expr instanceOf B)
        ((B)expr).doBStuff();
else
        expr.doAStuff();


Technically the compiler should not require the (B) cast -- so this
cast-approach is clearly equivalent to the switch. The only
difference is compiler awareness.


Anyhoo, i apologise once again for being completely clueless


--Oliver


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.