Staic typechecking in OO [was Re: Strong Types ?]

Sebastian Kaliszewski <>
4 May 2007 13:21:51 -0400

          From comp.compilers

Related articles
Strong Types ? (gygulance) (2007-04-26)
Re: Strong Types ? (2007-04-27)
Re: Strong Types ? ( (2007-04-28)
Staic typechecking in OO [was Re: Strong Types ?] (Sebastian Kaliszewski) (2007-05-04)
Re: Static typechecking in OO [was Re: Strong Types ?] ( (2007-05-06)
Re: Static typechecking in OO [was Re: Strong Types ?] (Sebastian Kaliszewski) (2007-05-14)
Re: Static typechecking in OO [was Re: Strong Types ?] ( (2007-05-16)
Re: Static typechecking in OO (Robert A Duff) (2007-05-18)
Re: Static typechecking in OO [was Re: Strong Types ?] (George Neuner) (2007-05-18)
Re: Static typechecking in OO ( (2007-05-28)
| List of all articles for this month |

From: Sebastian Kaliszewski <>
Newsgroups: comp.compilers
Date: 4 May 2007 13:21:51 -0400
Organization: tp.internet -
References: 07-04-12307-04-124 07-04-146
Keywords: types, OOP
Posted-Date: 04 May 2007 13:21:51 EDT wrote:
> One thing to note is that in general it is not possible to completely
> statically check a strongly typed OO programming language if it allows
> down casting, though i only mention this as it's a pet peave of mine
> :D

How about something like the following...

Instead of doing explicit runtime downcasting one has to define additional
functions dynamically dispatched on the type(s) of one of their

Then a compiler checks if those types being dispatched on fully cover type
subhierarchy of static type of the object being passed as an argument.

For example assume class hierarchy is like this:

    my_base_class <-- my_derived_1 <-- my_subderived_1
                ^ ^
                | |
      my_derived_2 my_subderived_2

my_base_class is abstract (pure virtual in C++ nomenctalture) so it can not
have any instances.

my_derived_1 has method foo() while my_derived_2 has method bar() while
my_base_class has none of those.

Now in one module there is a following definition (using C++ derived

void do_special_thing(virtual my_derived_1 &d1)

And in some other there is:

void do_special_thing(virtual my_derived_2 &d2)

So in such a language one could write:

for(polimorphic_container<my_base_class>::iterator i = my_container.begin();
          i != my_container.end();

Instead of today's C++:

for(polimorphic_container<my_base_class>::iterator i = my_container.begin();
          i != my_container.end();
      my_derived_1 *d1 = dynamic_cast<my_derived_1*>(&*i);

Notice, that compiler can statically check at every call site if there is no
such my_base_class subclass for which there is not any matching
do_special_thing() variant.

The above example is good for the aformementioned hierarchy, as my_derived_1
covers itself as well as my_subderived_1 & 2 while my_derived_2 covers
itself and my_subderived_3. my_base_class is abstract so it has no
possioble instances and thus does not need to be covered.

Besides, there is the 'classic' option:

switch class(obj)
      case my_derived_1:

      case my_derived_2:

Again, a compiler could (statically) check if above switch covers all the
possible variants.

Sebastian Kaliszewski

Post a followup to this message

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