Related articles |
---|
Strong Types ? hossein.rohani@gmail.com (gygulance) (2007-04-26) |
Re: Strong Types ? torbenm@app-6.diku.dk (2007-04-27) |
Re: Strong Types ? oliverhunt@gmail.com (oliverhunt@gmail.com) (2007-04-28) |
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 [was Re: Strong Types ?] gneuner2@comcast.net (George Neuner) (2007-05-18) |
Re: Static typechecking in OO oliverhunt@gmail.com (oliverhunt@gmail.com) (2007-05-28) |
From: | Sebastian Kaliszewski <Sebastian.Kaliszewski@softax.pl> |
Newsgroups: | comp.compilers |
Date: | 4 May 2007 13:21:51 -0400 |
Organization: | tp.internet - http://www.tpi.pl/ |
References: | 07-04-12307-04-124 07-04-146 |
Keywords: | types, OOP |
Posted-Date: | 04 May 2007 13:21:51 EDT |
oliverhunt@gmail.com 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
argument(s).
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_subderived_3
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
syntax):
void do_special_thing(virtual my_derived_1 &d1)
{
d1.foo();
}
And in some other there is:
void do_special_thing(virtual my_derived_2 &d2)
{
d2.bar();
}
So in such a language one could write:
for(polimorphic_container<my_base_class>::iterator i = my_container.begin();
i != my_container.end();
++i)
{
do_special_thing(*i);
}
Instead of today's C++:
for(polimorphic_container<my_base_class>::iterator i = my_container.begin();
i != my_container.end();
++i)
{
my_derived_1 *d1 = dynamic_cast<my_derived_1*>(&*i);
if(d1)
{
d1->foo();
}
else
{
static_cast<my_derived_2&>(*i).bar();
}
}
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:
obj.foo();
break;
case my_derived_2:
obj.bar();
break;
}
Again, a compiler could (statically) check if above switch covers all the
possible variants.
rgds
--
Sebastian Kaliszewski
Return to the
comp.compilers page.
Search the
comp.compilers archives again.