Re: Static typechecking in OO

Robert A Duff <bobduff@shell01.TheWorld.com>
18 May 2007 00:29:25 -0400

          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: Robert A Duff <bobduff@shell01.TheWorld.com>
Newsgroups: comp.compilers
Date: 18 May 2007 00:29:25 -0400
Organization: The World Public Access UNIX, Brookline, MA
References: 07-04-123 07-05-011 07-05-021 07-05-054 07-05-060
Keywords: OOP, types
Posted-Date: 18 May 2007 00:29:25 EDT

"oliverhunt@gmail.com" <oliverhunt@gmail.com> writes:


> Yes, but it achieves it's complete static type safety, if, and only
> if, there is a finite set of subtypes, all of which must be known at
> compile time.


Not exactly (see below).


> What happens when the cast fails?


It's certainly possible to devise language rules that make it
impossible for a downcast to fail at run time. For example, provide a
syntax that allows a parent type to name all of its immediate
subtypes. Make this optional. If you use this optional syntax, you
are arguably not being "object oriented" (for that particular part of
the program).


Provide some sort of case-statement on the run-time-known type.
Require that such case statements cover all the cases, or have a
default. Require downcasts to appear inside an appropriate branch of
such a case statement.


So (imagining some data structures inside a compiler, since this is
comp.compilers ;-)) we could say Optional_Expression has exactly two
subclasses, Expression and No_Expression. Expression has an unknown
set of subclasses, including Binary_Op, Unary_Op, etc. No_Expression
has no subclasses.


If X is an Optional_Expression, we could allow (making up syntax,
here):


        case Type_Of (X) of
                when Expression =>
                        ... downcast X to Expression ...
                when No_Expression =>
                        ... downcast X to No_Expression ...
        end case;


and


        case Type_Of (X) of
                when Binary_Op =>
                        ... downcast X to Binary_Op ...
                when No_Expression =>
                        ... downcast X to No_Expression ...
                when others => -- "default", for C folks
                        ... (downcast is illegal here)
        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;


The last case is illegal, because Expression has an open-ended number of
subclasses, so the case statement is not known to cover all the cases.


Note that Optional_Expression has an unknown set of subclasses,
but it has a known set of _immediate_ subclasses
-- that's what I meant by "not exactly" way up there.


- Bob


Post a followup to this message

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