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

On 16 May 2007 02:10:19 -0700, "oliverhunt@gmail.com"
<oliverhunt@gmail.com> wrote:


Sebastian Kaliszewski wrote:


>> >> 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);
>>
>> >> }
>>
>> > In case I misunderstood, and the virtual modifier in the parameter
>> > list for do_special_thing is telling the compiler to use a more
>> > specific type, the compiler will have to do some form of type check at
>> > runtime for the branching.
>>
>> virtual tells compiler to dispatch on actual (runtime) type.
>
>In which case it is no longer statically verifiable, as the compiler
>has to do run time dispatch and can not verify at compile time whether
>it should be calling the overload for my_derived_1 or my_derived_2,
>which are safe, or for my_derived_3 which would be unsafe.


For this example, you are correct.


In general there only has to be a runtime check where there is a
pointer or reference to a class which has further derived classes -
which is something that can be statically checked[*]. If the code is
dealing with an actual object, or if the pointer or reference is to a
leaf subclass, then the function or method call can be checked
statically and directly coded even if it is virtual.


[*] even in, e.g., Java where the class hierarchy can be extended at
runtime, it can be considered fixed for a particular class file at
compile time unless reflection is used.


I don't know of any compiler which actually does anything like this,
but AFAICS there is nothing which prevents doing it at least in
statically linked code (regardless of dynamic loading).




>> >> 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 problem is, your generic_list<my_base_class> can contain any of
>> > the subtypes, and the compiler can't determine at compile time what
>> > code to emit.


Unless analysis revealed that the generic_list was being used
homogeneously and the leaf subclass restriction held.


It could also be possible in a language which disallows mutation and
in which the list item type can be a union of the actual objects
rather than pointers/references to the base class. Because each
object's type could be known at the time it is added to the list and
the list can't be modified it could be possible to say statically that
the third item is of type X.


Again, I don't know of any such language, but it could exist.


George

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