Path: utzoo!attcan!uunet!bu.edu!snorkelwacker!bloom-beacon!eru!hagbard!sunic!ericom!eua.ericsson.se!euaabt
From: euaabt@eua.ericsson.se (Anders.Bjornerstedt)
Newsgroups: comp.object
Subject: Re: Do we really need types in OOPL's?
Message-ID: <1990Oct2.170910.4805@eua.ericsson.se>
Date: 2 Oct 90 17:09:10 GMT
References: <0yw10qr@Unify.Com> <411@eiffel.UUCP> <736@tetrauk.UUCP> <1990Sep25.135145.3460@kth.se> <3832@osc.COM>
Sender: news@eua.ericsson.se
Organization: Ellemtel Telecom Systems Labs, Stockholm, Sweden
Lines: 43

tma@osc.COM (Tim Atkins) writes:

>In article <1990Sep25.135145.3460@kth.se> d87-mra@dront.nada.kth.se (Magnus Ramstr|m) writes:

>>
>>This can be achieved in a strongly typed OOPL by having one class as the
>>ancestor of all other classes, letting your variables refer to that class
>>and using virtual messages only. Therefore a strongly typed OOPL can
>>be transformed into a weakly typed one, while the reverse is not true.

>	This is not really the case.  In a dynamically typed language
>any message can be sent to any object.  In a staticly typed language with
>a common base class only messages understood by the base class may be sent.
>In practice the latter is much harder to deal with and tends to lead directly
>to a need for MI and a lot of "adjective" classes to handle common protocol
>that needs to be mixed and matched to give the desired effect.  The situtation
>is somewhat ameliorated by genericity in Eiffel (parameterized types) and
>by casting in C++.  The latter is not always type-safe.  In C++ 2.x a virtual
>base, which is certainly likely in the presence of MI and polymorphism needs
>can not be legally cast to a derived pointer type.  I and others have develop-
>ed runtime work-arounds but they totally violate the supposed goodness of
>static typing.

Strong typing is not the same thing as static typing. Magnus Ramstr|m talks
about strong typing and you then go on and talk about static typing.
An example: In Simula you have the notion of requalification, which is like
casting in C or C++ but causes a runtime check. This gives you both type safety
(in the sense of only allowing messages to be sent to an object that it
is guaranteed to understand) and the oportunity for compiler optimizations.
Your program also runs the risk of being aborted at run time if a 
qualification fails. But at least your program aborts at the precise point
where it is trying to do something not intended by the programmer. 
Requalifying a variable to be of a more specialized type is then a special
case of an assertion.

-----------------------
Anders Bjornerstedt
Ellemtel Telecommunication Systems Laboratories
Box 1505
S-125 25   Alvsjo
SWEDEN

email: Anders.Bjornerstedt@eua.ericsson.se