Re: OO puzzle

[Ehud Lamm <mslamm@mscc.huji.ac.il>]

In article <83t14p$9ps$1@nnrp1.deja.com>,
  Robert Dewar <robert_dewar@my-deja.com> wrote:
> In article <83sq9g$5ml$1@nnrp1.deja.com>,
>   Ehud Lamm <mslamm@mscc.huji.ac.il> wrote:
> > I assume the importance of catching errors before runtime is
> > evident. Now can we do it nicely in this case?
>
> Evident, but not quite so neatly trivial. Run-time errors are
> of two kinds:
>
> 1. Statements that will always cause an error if executed. Such
> errors are bound to get caught by simple coverage testing.
>
> 2. Statements where the error is data dependent and there is no
> simple guarantee.
>

This is true, of course. Indeed one of the basic elements of OOP is the
late binding, which allows you things like polymorphic datastructures.
The price you pay is of course that some things are only checkable in
runtime. So far so good.

But if we delve into this, following your post, we get to less firm
ground.
Suupose I have a routine that receives a class wide type. Inside I
expicitly convert and treat it as some specific type.
If I pass an actual paramter that is class-wide (access object'class)
than, obviously, the valdity of the conversion can only be checked at
run time.
However if I pass a specific, and incompatible type - we can imagine a
compiler flagging the conversion as raising an exception. whether we
design a language to do this checking, and disallow such calls is,
naturally, a deisgn choice. But as opposed to the first example - this
checking seems possible to do (at least in limited cases like this).

The issue we discussed was an example of paramter delcartions in
Eiffel, that if checked before runtime, provide more checking than is
achied by some Ada examples that ostensibly defer the check to runtime.

Your classifciation is correct, but in itself doesn't provide the
prescriptive answer of how to design a language in such a way as to
ensure as much can be done during compile time, as possible without
hurting expressablity to much. This question is naturally not a
question that can be answered shortly and with a defnitive answer.
Hence we see some differences even among mostly similiar languages.

The "system validty" issue in Eiffel, is such an issue, and comments
about it are welcome. The first question, though, is if it can be
checked before runtime. Tucker's response seems to imply that the
answer is no. [but also brings in the question of link time checks]

--
Ehud Lamm mslamm@mscc.huji.ac.il
http://purl.oclc.org/NET/ehudlamm
Check it out and subscribe to the E-List


Sent via Deja.com http://www.deja.com/
Before you buy.